marahmarie: my initials (MM) (Default)

I wonder if I'll get used to it. My current online project is: "Make Firefox not use so much RAM it stops responding" and boy howdy, has it been a project. I'm still getting two or three (Not Responding) white title bar freeze-ups per start-up and Firefox is taking between a few and 20 minutes to just calm down and be a browser already, but once it does, it goes pretty fast. What I've done to get it that way is almost unreal.

Starting last week:

  • Completely uninstalled Firefox; removed all personal data, files and folders, reg entries
  • Installed Firefox latest from scratch. Because Mozilla couldn't find an old copy of Firefox, I became a new user, so they kindly gave me the 64-bit version with multiprocess (e10s)
  • Installed add-ons, then kept uninstalling any that weren't e10s compatible (how to tell: the add-on list will show a message saying the browser isn't multiprocess compatible. That means one of the add-ons isn't playing nice)
  • Got rid of LastPass, which by itself was hammering RAM
  • Dropped Web Dev by Chris Pederick (which killed me; it's my favorite add-on besides ABP) and taught myself how to at least find the "Style Editor" in Firefox's Web Dev (there's not another panel in that tool that I know from Adam)
  • Dropped custom themes; am using Firefox's default dark theme

And between all that, I'm still having consistent, repeated browser freezes for the first 5-20 minutes until Firefox finally becomes usable (that's on first run; on any subsequent runs the freeze total is about the same but the wait time to get through them is usually quite a bit less).

Remaining add-ons are:

  • ABP
  • Add-on Compatibility Reporter
  • Archive Url
  • Clean Uninstall
  • FlashDisable - not sure if I need it or if it works - but it doesn't disable the video embedded in the article I linked to in my last linkcatcher post (ETA, 8-28-17: removed)
  • Ghostery - hammers RAM, but I like it
  • Google search link fix - not sure if it works (ETA, 8-28-17: works better than the add-on discussed next) I prefer the version from the guy I worked with on the JS to add to my Google search userscript, but even his doesn't work on topfold, onebox results and isn't e10s compatible
  • gui:config - I could probably scrap it and about:config everything; not what I thought (ETA, 8-28-17: removed)
  • HTTPS Everywhere - another RAM eater, but practically indispensable (don't see why the same tech can't be built into the browser)
  • IP Address and Domain Information - DT Whois add-on replacement
  • KeeFox - LastPass replacement (ETA, 8-28-17: removed; put Lastpass back)
  • TrafficLight - WOT replacement; WOT is e10s ready not e10s ready, and it eats so much RAM. But TrafficLight thinks eBay is a scam or phishing site and blocks pages and tries to whisk you away and just grrrrr
  • WayBack Machine - I used the in-house Firefox experimental of this add-on (I think after being tipped off to it by [personal profile] darkoshi - or was that the other way around?) and wanted it back

In all of that you'll see three of my favorites are conspicuously MIA: Web Dev by Chris Pederick, ColorPicker and MeasureIt. That's because all three add-ons are rolled up into Firefox's native Web Dev. The last time I tried them, MeasureIt no longer worked (blank dialog boxes), ColorPicker was acting pretty janky, and Web Dev wasn't e10s compatible, so I felt like I had no choice but to stop using them if I was going to make Firefox stop crying big, RAM-filled tears.

But native Web Dev is weird. I don't know if you can kill all the extra panels but I hate them. When I'm in their pretentiously named "Style Editor" I don't want a bunch of panels: I want my CSS. The Web Dev add-on did that, and displayed dark-on-light or light-on-dark (I have blurry vision and astigmatism so light on dark is out) but with native Web Dev, the editor color must match browser color. I prefer a dark browser and light editor, so it's forced me into light-on-dark editing.

And in the Web Dev add-on, when you make live CSS changes they "move" into view. In native Web Dev, they "slide", and it makes me feel like my stomach is turning, watching page elements start sliding around. I can't explain it.

The font is also too small and I have no need to work in syntax highlighted code because I generally know what and where things are, so the syntax highlighting is distracting, because I'm probably (not kidding, just not diagnosed yet) a bit ADD.

So from an accessibility standpoint, it seems native Web Dev needs some work. Knowing Mozilla, though: "Oh, that doesn't matter because we're re-writing the engine for that, it'll be ready in 2019!" and I just...grrrrrr.

marahmarie: my initials (MM) (Default)

Don't get me wrong: I love Web Dev; if I didn't love it, then like most add-ons in the entire world, I wouldn't use it. It does things Firefox's built-in Web Dev tools can't do and sits up there in my toolbar begging me through my peripheral vision to click on any of its many tools so convincingly that I have a hard time not using it just to use it. I don't think I've found all the tools it has yet and that's with steady, regular use going back at least five years.


The Dev in Web Dev either deliberately broke or else accidentally lost right-click functionality back in '11 or '12 and never bothered to fix it. It's on his list, of course; so is making pigs fly, if you look hard enough (alright, I may be kidding about that, but for all the difference it makes). Luckily I'm sorta handy with a keyboard - and the keyboard functionality, with some exceptions, still works - so it's Ctrl+A, Ctrl+C, Ctrl+V, Ctrl+X, Ctrl+Z and Ctrl+Y all the way. That's bad enough, OK?

On Nightly it's not just all-keyboard-all-the-time FTW, but - but! Web Dev sometimes loses focus so that when you're in the CSS live edit console and hit, say, Ctrl+A, you wind up selecting all the text on the page instead of in the console. It's a seemingly random thing so you never know when it will happen nor what to do to prevent it (fwiw, it seems like a rather exotic mutation of this bug, which he thought he had fixed). Figuring out how to fix it yourself is even harder because when you lose console focus the CSS is uneditable, so when you go to hit say, the backspace key, nothing happens. I stumbled on the answer entirely by accident.

You can easily "fix" the freeze by highlighting and deleting any CSS in the console. It can be any amount of CSS - one character, the entire style sheet or any amount of code in between. Once you delete something, anything, the console "wakes up" and works again. So it's highlight, delete and Ctrl+Z (assuming you didn't want to delete anything) then proceed as usual. Until the next problem, which you'll probably run into shortly.

The console freeze is a strong clue to the next problem, and usually shows up within minutes of you "fixing" the freeze by deleting something: the "live" in live edit stops working. You can still use the console - it's not frozen - the damn page is. So say you're changing margins, padding and backgrounds furiously only to notice many seconds or minutes later that nothing's happening on the page - this is because somehow the live link between the console and page has been broken. You'll have to reload the page to fix it, but reloading will often loop you right back to the first issue in which the console freezes harder than a rock again.

After enduring many hours of this I've decided if the Dev in Web Dev knows about this (but doesn't fix it) then there's a good chance he's not just time- and cash-strapped but is also perhaps a sadist. It's made editing feel like plunging into the seventh circle of hell (yes, in hell we'll have nothing but really crappy editing tools...kind of goes with the overall atmosphere down there, I guess).