Can't disable code folding in Browser Toolbox (with or without fission)
Categories
(DevTools :: Style Editor, enhancement, P3)
Tracking
(Not tracked)
People
(Reporter: aminomancer, Unassigned)
Details
(Whiteboard: [not-a-fission-bug])
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0
Steps to reproduce:
Style editor has been extremely buggy for me the last couple weeks. As soon as I type/edit anything in a stylesheet of more than ~5,000 lines, it does this bizarre thing where it erratically undoes whatever I edited and scrolls up a bit. If I hit ctrl+z it scrolls all the way to the top of the screen. I have to hit ctrl+z like 3 times because it seems to be undoing nonsense edits that the devtools module made by itself.
It's really hard to explain exactly what this looks like. If I type really slowly and wait 2 seconds then it will merely scroll up on its own without messing up what I typed. But if I just type normally it will create a huge mess, undoing most of what I type and scrolling all over the place. And hitting ctrl+z causes a complete disaster. As an example I just tried to type a very short and simple rule, body {color: white;} and it somehow ends up as boloie} and I end up scrolled like 100 lines above where I was typing.
I've tried changing every setting I can but nothing has helped. The one thing I'm thinking is that it has something to do with code folding, because every time this happens, the code folding arrows (the collapse/expand buttons) disappear for a second then reappear. Like when I say that it scrolls up 2 seconds after typing, and starts undoing my typing if I keep typing during that interval, the arrows are disappearing at the same time. I can type one character, and within 2 seconds it will scroll up and the code folding arrows will disappear for half a second. So I feel like this has something to do with it, given that I haven't seen any other correlation with anything.
The problem is I can't get the browser toolbox (the one that actually has this problem, the content toolbox works fine for some reason) to acknowledge my pref devtools.editor.enableCodeFolding = false. This pref does work in the regular content toolbox, but doesn't work in the browser-contexted toolbox, which is the main one I use to live debug stylesheets.
Actual results:
- Total word processing catastrophe
- Can't disable code folding in browser toolbox but can disable it in content toolbox
Expected results:
- Normal typing in editor/scratchpad like FF had for 6 years prior to this
- Ability to disable code folding in the browser devtools
Comment 1•5 years ago
|
||
Adding [fission-] whiteboard tag since this happens with or without Fission.
Comment 2•5 years ago
|
||
I'm going to triage this bug for the enhancement suggested (being able to toggle code folding in the browser toolbox). I think we should file another bug for the performance / usability issue for stylesheets > 5000 lines.
Comment 3•5 years ago
•
|
||
In the meantime, there are some workarounds you can use to set the preference in your Browser Toolbox profile. Since it uses a different profile from the regular content toolbox, the key is to be able to open a browser window for this profile and then navigate to about:config.
The most consistent way to do that is:
- open Browser Toolbox
- click the "..." button in the Browser Toolbox (top right)
- click the "Documentation..." item
This will open a browser window, which will be using your Browser Toolbox profile.
From there, you can navigate to about:config, flip the preference. Probably quit and restart the browser toolbox to make sure the pref will be re-read correctly.
| Reporter | ||
Comment 4•5 years ago
|
||
Thanks for the tip. And I now agree with you that the code folding thing seems to be unrelated to the bug I've been experiencing. Unfortunately I think I toggled the code folding setting a while back by directly editing the prefs, and then discovered that disabling code folding doesn't actually solve the main issue that's making the style editor practically unusable. It seems like you're right that it does seem to have something to do with the length of the stylesheet. Although my main stylesheet is about 8000 lines, I realized I actually still get the bug on anything longer than like 1000 lines. When I test on much shorter stylesheets, like most of the native firefox UI sheets, there is no issue. But I don't know if it can really be called a performance issue, since I'm getting the exact same behavior on my laptop as on my rendering workstation, which has pretty much no performance issues with any other part of the browser.
Speaking of which, the one other bug I've been getting that seems performance-related is that when I type into the urlbar immediately after opening a new tab, within half a second or so, it erases whatever I type and basically empties the input box so instead of typing "google" I end up typing "ogle" or something like that. I've posted a bug about this and it was even resolved... for like a week. Then it came right back and it's been like that for ~2 months. I'm told it is due to the size of my places db, but I'm pretty skeptical of that because in many years of using firefox with the same places db, I never ran into that problem until one fateful update. And similarly, the problem is just as bad on my laptop as it is on a threadripper with 64GB of 3200mhz ram. I'm sure it's possible but it seems unlikely that an unavoidable performance hitch would manifest identically on both these computers.
And then every other area of browser performance is perfectly fine, if not exceptional. I'm able to completely disable dom.min_background_timeout_value on that PC and have like 400 tabs open without any type of lag or stuttering. And instead of lag or stuttering, the issue I get with the style editor is this dramatic, erratic behavior when I type anything into a stylesheet. I don't even know how to describe it, maybe I should just record a video of it. I've been using the devtools pretty frequently on that workstation for like 3 years and never seen anything like this until a month or 2 ago. Maybe there's a performance issue at the root of it, I'm no expert, but it does seem like some random regression introduced a legitimate bug. It's not like that stylesheet has grown or anything, actually I think I've trimmed it down over the past few months.
Anyway, I wouldn't normally use such a long stylesheet in the first place, but I'm not sure if I have any other option. I know I could register an arbitrary number of inline agent sheets with alice0775's autoconfig js loader, but there's a longer delay in loading stylesheets by that method during startup than the native system that loads userChrome.css. So the UI would visibly change during startup in a pretty major, jarring way. I don't know if there's any way to chain more CSS files through userChrome.css or get firefox to load additional files in the UChrm directory by the same method it loads userChrome and userContent.css. I guess if anyone knows a way to do that, that would solve my problem too. Maybe would be for the best since I'd like to organize that stylesheet into more specific units anyway.
Comment 5•5 years ago
|
||
I recommend filing separate bugs for these other performance problems. Recording a Firefox performance profile and sharing a link in the bug report is a big help for diagnosing performance problems and redirecting them to the right team.
Here are instructions for recording a performance profile:
I know I've seen the "type google in the address bar but only oogle appears" bug months ago, but it was fixed.
Comment 7•5 years ago
|
||
This is most likely related to Bug 1679043 which has been recently fixed (Firefox 86)
Description
•