Dataloss and productivity issue in nightly 64/beta 63
-
- Posts: 496
- Joined: November 5th, 2002, 1:35 pm
- Location: Tallinn, Estonia
Dataloss and productivity issue in nightly 64/beta 63
https://bugzilla.mozilla.org/show_bug.cgi?id=1487632
Of this bug I cannot use developer preview (actually beta) anymore and would not be able using FF at all.
Usage scenario of mine if I need to open a new page:
0. in any tab
1. ctrl-L
2. type the URL
3. hit AltGr-Enter with one hand
With beta 63 I loose important unsaved data, have to click back, have to follow what keyb layout I have active, so the productivity is now 50% and I have to change to some other browser.
For me FF 63 is useless now.
Does anyone have the same problem now? How could the bug given a P1 importance?
Of this bug I cannot use developer preview (actually beta) anymore and would not be able using FF at all.
Usage scenario of mine if I need to open a new page:
0. in any tab
1. ctrl-L
2. type the URL
3. hit AltGr-Enter with one hand
With beta 63 I loose important unsaved data, have to click back, have to follow what keyb layout I have active, so the productivity is now 50% and I have to change to some other browser.
For me FF 63 is useless now.
Does anyone have the same problem now? How could the bug given a P1 importance?
- Snake4
- Posts: 1841
- Joined: December 27th, 2017, 4:03 am
- Location: Australia
Re: Dataloss and productivity issue in nightly 64/beta 63
there is no Beta 63? where did you get 64 Nightly from?
-
- Posts: 496
- Joined: November 5th, 2002, 1:35 pm
- Location: Tallinn, Estonia
Re: Dataloss and productivity issue in nightly 64/beta 63
Screenshot of Developer edition:
https://1drv.ms/u/s!Av2nuidly48bk6cAuTamvodurLXdHQ
https://1drv.ms/u/s!Av2nuidly48bk6cAuTamvodurLXdHQ
- Snake4
- Posts: 1841
- Joined: December 27th, 2017, 4:03 am
- Location: Australia
Re: Dataloss and productivity issue in nightly 64/beta 63
thats the DEVELOPER Edition of 63, not the actual official Beta of 63, an 64 wont be released toThursday at the latest i would of thought . IMO if you wanna use Beta software or Alpha software your on ya own. dont expect it to be stableEzh wrote:Screenshot of Developer edition:
https://1drv.ms/u/s!Av2nuidly48bk6cAuTamvodurLXdHQ
-
- Posts: 154
- Joined: March 7th, 2011, 11:22 am
Re: Dataloss and productivity issue in nightly 64/beta 63
You could try changing the default urlbar behavior to open in a new tab with `browser.urlbar.openintab`.
I just had a look at the associated XBL bindings (_whereToOpen and maybeCanonizeURL), but they don't use the `AltGraph` state from KeyboardEvent. The behavior in Chrome and Firefox recently changed to not set `ALT` and `CTRL` when `ALT RIGHT` is pressed in Windows on an `ALTGR` keyboard layout due to a W3C discussion, which is probably why you're seeing a regression. I'm gonna try to add AltGraph handling these methods in a`bindings.xml` (doesn't work) or unzip/edit/rezip `omni.ja`, but I can only test the behavior on linux. If this gets fixed it should probably be uplifted as well...
edit: I should also mention the the urlbar is being rewritten right now in the quantumbar project, but that will likely take a couple more months at least. So any fix that happens should have test-case for different locales so this doesn't regress again.
edit2: I don't get it to recognize level 3 shift in linux as AltGraph, possibly due to my weird keyboard layouts...
Anyway, here's what I did and what you could try:
[*] Unzip omni.ja to a temporary directory
[*] Change the `_whereToOpen` function at line ~719 `chrome/browser/content/browser/urlbarBindings.xml` as follows:
[*] Re-zip the omni.ja, place it back and start the browser with the `-purgecaches` argument to make sure the old bindings aren't cached anywhere (not sure if this is still needed).
edit3: chrome.ja, not omni.ja of course
edit4: The fix works on Plasma Wayland, but not on X11. Could be that XWayland/Wayland uses a different kb layout or that the keyboard handling code there is just less buggy.
edit5: jsfiddle for testing, though I probably won't be able to get any further, hopefully the fix works for you on Windows.
edit6: No, it's omni.ja ... stupid brain -.-
I just had a look at the associated XBL bindings (_whereToOpen and maybeCanonizeURL), but they don't use the `AltGraph` state from KeyboardEvent. The behavior in Chrome and Firefox recently changed to not set `ALT` and `CTRL` when `ALT RIGHT` is pressed in Windows on an `ALTGR` keyboard layout due to a W3C discussion, which is probably why you're seeing a regression. I'm gonna try to add AltGraph handling these methods in a
edit: I should also mention the the urlbar is being rewritten right now in the quantumbar project, but that will likely take a couple more months at least. So any fix that happens should have test-case for different locales so this doesn't regress again.
edit2: I don't get it to recognize level 3 shift in linux as AltGraph, possibly due to my weird keyboard layouts...
Anyway, here's what I did and what you could try:
[*] Unzip omni.ja to a temporary directory
[*] Change the `_whereToOpen` function at line ~719 `chrome/browser/content/browser/urlbarBindings.xml` as follows:
Code: Select all
let altEnter = event && (event.altKey || event.getModifierState("AltGraph"));
edit4: The fix works on Plasma Wayland, but not on X11. Could be that XWayland/Wayland uses a different kb layout or that the keyboard handling code there is just less buggy.
edit5: jsfiddle for testing, though I probably won't be able to get any further, hopefully the fix works for you on Windows.
edit6: No, it's omni.ja ... stupid brain -.-
Last edited by johnp_ on September 5th, 2018, 8:50 am, edited 1 time in total.
-
- Posts: 496
- Joined: November 5th, 2002, 1:35 pm
- Location: Tallinn, Estonia
Re: Dataloss and productivity issue in nightly 64/beta 63
Where can I find the chrome.ja? I cannot find it in profile nor FF dir.
-
- Posts: 154
- Joined: March 7th, 2011, 11:22 am
Re: Dataloss and productivity issue in nightly 64/beta 63
Sorry, I'm an idiot, I linked the omni.ja MDN entry and actually did it myself but for some reason my brain wrote `chrome.ja` everywhere -.-
It is in the installation directory in the folder `browser`. Better extract it somewhere else though, since some of the contents extract into pre-existing folders otherwise.
Updating the browser may overwrite your modified omni.ja when there were relevant frontend-changes in the update.
Also make a backup copy of the existing omni.ja, since re-packing the archive correctly can be a bit hard (explained in the linked MDN)
It is in the installation directory in the folder `browser`. Better extract it somewhere else though, since some of the contents extract into pre-existing folders otherwise.
Updating the browser may overwrite your modified omni.ja when there were relevant frontend-changes in the update.
Also make a backup copy of the existing omni.ja, since re-packing the archive correctly can be a bit hard (explained in the linked MDN)
-
- Posts: 496
- Joined: November 5th, 2002, 1:35 pm
- Location: Tallinn, Estonia
Re: Dataloss and productivity issue in nightly 64/beta 63
I finally found time to try it out.
It works on Windows!
Tnx!
It works on Windows!
Tnx!
-
- Posts: 496
- Joined: November 5th, 2002, 1:35 pm
- Location: Tallinn, Estonia
Re: Dataloss and productivity issue in nightly 64/beta 63
It works in URL bar, but not in search bar.
-
- Posts: 154
- Joined: March 7th, 2011, 11:22 am
Re: Dataloss and productivity issue in nightly 64/beta 63
Yeah, that's likely `chrome/browser/content/browser/search/search.xml` lines ~284 and ~1778 in the `handleSearchCommand` method(s) (the first one is for the search bar, the second one seems to be for the autocomplete dropdown).
Apply roughly the same change as before (the variable has a slightly different name):
Frankly, given the nature of the regressing change one would have to audit *all* usages of `.altKey` and `getModifierState("Alt")` to see if it makes sense to also support any of those actions with AltGraph...
I'll see if I find some time in the coming days to open a bug report and maybe whip up a patch at least for the address bar and search bar, because I think it makes sense for one-handed keyboard usage and the possible dataloss isn't good either.
Note to self: Line 889 may also need changing, seems to be clicking on auto-complete popups
Apply roughly the same change as before (the variable has a slightly different name):
Code: Select all
if (((aEvent instanceof KeyboardEvent && (aEvent.altKey || aEvent.getModifierState("AltGraph"))) ^ newTabPref) &&
I'll see if I find some time in the coming days to open a bug report and maybe whip up a patch at least for the address bar and search bar, because I think it makes sense for one-handed keyboard usage and the possible dataloss isn't good either.
Note to self: Line 889 may also need changing, seems to be clicking on auto-complete popups
-
- Posts: 182
- Joined: September 9th, 2018, 1:41 pm
Re: Dataloss and productivity issue in nightly 64/beta 63
No offense intended, but if you changed your sequence to this would that fix the problem?
1. ctrl-T instead of ctrl-L
2. type the URL
3. hit Enter
1. ctrl-T instead of ctrl-L
2. type the URL
3. hit Enter
-
- Posts: 496
- Joined: November 5th, 2002, 1:35 pm
- Location: Tallinn, Estonia
Re: Dataloss and productivity issue in nightly 64/beta 63
In 67 and in 68 beta it is still an issue. I offered to donate for fixing this, but no one cares...