When typing URL soon after opening a new tab, sometimes a few beginning characters get removed after half a second
Categories
(Firefox :: Address Bar, defect, P3)
Tracking
()
People
(Reporter: aminomancer, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:81.0) Gecko/20100101 Firefox/81.0
Steps to reproduce:
- First of all I have fission.autostart disabled if anyone's wondering
- Open a new tab with the button or ctrl+T
- Immediately start typing "blah blah blah" as soon as possible after opening the new tab
Actual results:
- Sometimes: in the middle of typing "blah blah blah" the urlbar input field 'resets', meaning by the time I get to "bl" everything is deleted and I end up typing "ah blah blah" instead.
- When CPU usage is higher, this happens way more often, and the 'reset' ends up coming later which means it deletes way more characters.
Expected results:
First off I should say a lot of people including me submitted a suspiciously similar bug like 20 revisions back: https://bugzilla.mozilla.org/show_bug.cgi?id=1652217
That bug, which apparently was caused by a variable delay in searching the places DB, was fixed about 2 weeks ago: https://bugzilla.mozilla.org/show_bug.cgi?id=1652024
In that bug, when you typed into the urlbar, if you hit enter too soon after finishing typing your query, it would shave characters off the END of your query. If you tried to type "blah blah blah" you'd end up submitting "blah blah bl" instead. In this case something very similar is happening, except instead of shaving characters off the end, in practice it's shaving characters off the beginning. And it's not happening because you hit enter before the lookup finished—it's apparently happening because the input field's value is literally resetting while you're typing, eliminating whatever characters you had typed before the reset.
I don't know if this is mechanically related to the previous bug, but I do know that I only noticed this bug after the previous bug was fixed... and that I noticed it immediately after the previous bug was fixed. I update manually so I don't normally update every night. But I was following that bug closely as it was noticeably impeding my use of firefox, so I'm pretty sure I updated the moment that fix was reported on bugzilla. So I got the impression that this bug was somehow, whether directly or indirectly, precipitated by the fix for the previous bug.
Anyway, the best way to reproduce this would be to run some kind of light CPU benchmark in the background before you start. However, this happens to me practically all the time, not just when I'm running a lot of stuff in the background. I just mean that it's a lot more extreme and frequent under those conditions. When CPU usage is high, you don't need to start typing that soon after opening a new tab for the bug to occur. You could wait a whole second and still have it reset while you're typing.
It is an omnipresent problem, but it's hard to consistently reproduce on-demand because the more you try to do it, the less it seems to happen. I don't know of a good computer science analogy so I'll just say that it's like this happens when the engine is cold, and the more you try to reproduce the bug, the engine revs up and gets warmer, reducing the chances of it happening. It tends to happen to me when I've been on the same tab browser for 30+ minutes and then open a new tab to type in a google search.
I have also tested this on a new/blank profile as well as my main profile. It happens less frequently on the new profile but it still happens. I don't know if the reduced frequency is due to the lower size of the places DB, or if it's because my main profile has a lot of extensions, userscripts, css rules etc. that I can only assume would increase the computational load on the isolated process. I haven't tried to confirm that but I will if someone wants me to.
Sorry if this is unclear, it's a hard bug to put into words. I'll try to clarify if anyone has any questions I can answer.
Also I do recognize that there are limitations on a browser. This might be less of a broken feature than it's a nuisance caused by some kind of resource limitation, so the line between a defect report and an enhancement request are sort of blurry here. But this limitation never existed until recently, meaning I've used firefox for a decade without needing to slow down and hesitate before typing my search queries and URLs. I'm not really able to practice that habit at this point in the game, can't teach an old dog new tricks and all that.
I think if this is a limitation caused by new code supporting some major improvement like fission, then hopefully it can be worked around, but if not then maybe it's worth reevaluating some priorities. At least for me, being able to type search queries into the urlbar as soon as I open a new tab is more important than isolation. I just don't want to have to regulate how soon I start typing when I open a new tab, because it's a routine I have to repeat like literally hundreds or thousands of times per day. And I do type pretty quickly but there must be millions who type faster than me. So if it's affecting me I'm sure it's affecting many other people.
|
Reporter | |
Comment 1•4 years ago
|
||
Also in case anyone was wondering it's not something you'd only experience running firefox on a potato. The computer I use most and the one I first noticed this on is a threadripper 1950X with 64GB of memory at 3200Mhz, and the OS and firefox are on a 970 evo+, so it's the complete opposite of where I'd expect a performance related problem. Not to mention, I don't notice it happening any more or less frequently on my dell XPS 15. The severity and frequency seem to be correlated with CPU usage but not necessarily core count or clock speed. Oh and I haven't tested it since I wouldn't expect it to matter, but I haven't noticed GPU usage having any effect. I haven't tested whether memory usage has any effect either. I just know that it's definitely not caused by a lack of memory because the workstation only ever reaches more than like 20% memory usage when I'm rendering something. I experience this bug on a pretty much constant basis (like right now) with RAM usage around 11/64GB.
By the way, on my main profile I have around 350 tabs, but most of them are discarded, e.g. not loaded. I don't know if discarded tabs should have any effect on something like this, I just know the new profile only has 1 tab and I haven't tried closing all of them on the main profile to see if it makes a difference. But even if it does, the new profile still runs into this bug sometimes, just to a lesser degree.
|
||
Comment 2•4 years ago
|
||
Bugbug thinks this bug should belong to this component, but please revert this change in case of error.
|
||
Comment 3•4 years ago
|
||
There's been some churn around this, but bug 1653436 has been reopened and this seems similar enough to dupe there. This bug will be noted in that bug when I dupe it, but if you have anything more to add, please comment there.
|
||
Comment 4•4 years ago
|
||
I'm not so sure it's the same as bug 1653436, that bug was about losing characters at the end/middle of the string and was/is caused by some timing changes we made to heuristics, while this is probably another already known bug about the urlbar reset on switching tabs asynchronously, that cuts the initial characters
|
|
||
Comment 5•4 years ago
|
||
If you can reproduce easily enough, it would help us a lot if you could test some old builds and tell us when the problem became more evident. You can do that using mozregression https://mozilla.github.io/mozregression/ that will allow you to start for example from --good NN (pick a version where you think you didn't have the bug) and more or less restrict the range where the problem started happening.
Fwiw this sounds similar to bug 1588324, and there may be more dupes.
|
|
Reporter | |
Comment 6•4 years ago
|
||
Yeah I agree they don't really seem like the same bug. I don't do regressions anymore because it usually deletes my session store. If I only go back a couple revisions it's usually been fine, but going back any more than about a week ago it wipes all my tabs and even some extension data. I've tried backing up my profile so I can restore it after, but when I restore the session store, upon starting up there are still no tabs and it overwrites some of the session store files. Idk if anything's different now since I haven't tried it in almost a year due to fear of losing all my tabs and mainly the local storage for my extensions, some of which are really inconvenient to restore. Like technically I could back it up by literally copying all the keys in the inspector, one by one, and then restore them by hand later, but I don't really have the time. If you know a foolproof way to restore the session store then I'll try it though
|
|
Reporter | |
Comment 7•4 years ago
|
||
Maybe it's due to my using an old profile. Like there are lots of files in my profile folder that don't exist in a new profile folder, I guess they're obsolete or whatever. I have been using this profile for like a year, but I copied the search engines and places and other files from an even older profile when I made it. So maybe there's something wrong with my profile itself and when I regress too far back it doesn't recognize the files and replaces them with new ones. My only other profile is just a blank profile I use for debugging, so I don't know whether that one is getting wiped too. Plus, even if I select the blank profile at startup it still messes up my main profile
|
|
||
Comment 8•4 years ago
|
||
(In reply to shmediaproductions from comment #6)
Yeah I agree they don't really seem like the same bug. I don't do regressions anymore because it usually deletes my session store.
mozregression always uses a new temporary profile and never touched your profile. You should only use mozregression to do that, never do it manually. If the bug requires your profile, you can copy it to a new one with a different name and ask mozregression to use that.
If you are in doubt, you can always backup your whole profile anyway, that is always a good idea!
So one of the first things would be to check if you can reproduce in a new profile, if you can then it will be much easier to find a regression using the tool, otherwise it requires a bit more work.
|
|
Reporter | |
Comment 9•4 years ago
|
||
Thanks for the response, that's actually what I'm referring to when I say it wipes my session store. I was using mozregression when this happened, and never tried to do a regression manually. mozregression-gui used to work fine for me, like 15 months ago. I always pick a new profile in the profile selector, it still deletes my main profile's session store, I think because during the regression the updater starts an instance of firefox that for some reason doesn't obey the profile selector. Like I'll try to explain what happened, this only happened to me twice but that's because I stopped using mozregression entirely after this happened. I start up mozregression-gui and run a new bisection, the first couple builds it seems to work fine, but it starts to open multiple instances of firefox after a while, causing a warning where I have to manually close down firefox and resume the regression. And that's the point where my profile gets opened, one of the windows will be a blank window, but the other window will be my main profile. And I'm able to tell it's my main profile because it uses my extensions, scripts, CSS etc. It'll be missing all my tabs but due to the UI modifications it's apparent that it's my profile. And then when I finish the regression and reopen firefox using that profile, I'll be logged out, all my tabs will be gone and all my extensions which use storage.local will be effectively reset. Then I close firefox, and I copy my backup of the profile folder over to restore it. I open it up, and I'll be signed into my firefox account again and everything that's synced will be restored, but all the local storage and tabs will still be gone.
In the past I tried a lot of troubleshooting to get all my stuff back. I tried copying JUST the profile files that I believe are relevant to local storage and session store. But those are the files that it seems to overwrite as soon as it boots up. Maybe there's some CRC file that gets updated when the browser starts and my backups do not match it anymore? Anyway, I also tried rolling back firefox itself to an older build, the last build in the regression before it started up with my main profile. Thinking that maybe my profile files were just getting overwritten due to an incompatibility, so if I rolled back I could get it to start up with my storage intact and I could then proceed to update normally. No dice though.
Actually, concerning your point that you shouldn't do regressions manually: it never occurred to me but maybe I could safely do a regression if I did it manually. The problem in my case seemed to be that mozregression was going too fast or something. Like every time it wiped my storage, it coincided with mozregression opening a new instance of firefox before the old one closed. Which seems to cause it to skip my profile selection and go straight to the default profile for some reason. So ironically I think my problem was caused directly by mozregression and might actually be avoided by rolling back firefox manually. I'd try that but it's way slower and I'm not sure if it's really safe either.
|
|
Reporter | |
Comment 10•4 years ago
|
||
And I can't remember if this actually coincided with my storage getting wiped but mozregression sometimes seemed to try to open even more than 2 instances at once. It only ever successfully opened 2 windows at one time, like first it opens one with the blank profile, then it opens a new one with MY profile before I can close the blank profile's window. And THEN it seems to try to open yet another instance of firefox, but this gets blocked for some reason, and only prompts the dialog you get when you try to open multiple instances of firefox, I normally only see that dialog when I accidentally click my custom toolbar button for the browser level devtools while I already have one instance of the toolbox open. Anyway, say it went through 30 different builds, then during 1 or 2 of those, it would start up the next build before I had time to test everything and close the build that's already open. The other 28 or 29 windows would be fine, but sometimes it'd just start up on its own. This happened on 2 attempts in a row and I never tried it again after that so I don't know how frequent it was. Maybe the problem was with my firefox installation or maybe it's already been solved, but the consequences are just too devastating to risk trying it again, unless I can find out how to truly restore a backup without having firefox overwrite DBs like storage.sqlite and storage-sync.sqlite upon startup
|
|
||
Comment 11•4 years ago
|
||
The severity field is not set for this bug.
:adw, could you have a look please?
For more information, please visit auto_nag documentation.
|
|
||
Updated•4 years ago
|
|
|
||
Updated•4 years ago
|
Description
•