Invitation to use Firefox Developer Edition in Pale Moon?

[suzyne]

I am using 33.0.0b1 and I opened Inspect Element (the Developer Tools) and a pop-up prompt appeared inviting me to use the Firefox Developer Edition.

I was so surprised that I made a screen capture! How could that happen?



Especially weird because it says "our first browser made just for you."

[RealityRipple]

UXP /devtools/client/framework/dev-edition-promo/*; inserted by /devtools/client/shared/doorhanger.js. I'm pretty sure the doorhanger module doesn't do anything other than insert that.

Weird Dependency Notice:
/image/test/browser/browser_docshell_type_editor uses the dev-edition-logo.png to test for a content->chrome privilege leak.

[athenian200]

It sounds like some old code from Firefox has been activated somehow that wasn't before. Pale Moon was forked from Firefox long ago, and so a surprising amount of hidden Mozilla advertisements are lingering around in the codebase waiting for triggers that aren't obvious. There are very rare instances where this happens, but I haven't seen anything like this in years. Obviously I've seen some of it with Epyrus because it was hard to remove every bit of the Thunderbird branding, but with Pale Moon this was something I hadn't seen in years.

https://xref.palemoon.org/goanna-centra ... omo.xul#18

I guess since it was buried off in DevTools in the platform code, we didn't see it... kind of unnerving to realize a piece of Mozilla branding was being distributed this whole time, albeit hidden behind a trigger that was rarely activated. But yeah, I guess that's one small issue... we wouldn't have been looking for Mozilla branding in the platform, only in the application side. I would have expected the separation to be a bit cleaner...

[Moonchild]

Maybe it's version-triggered?
It's beta-channel en-US only. So it would never show up on release versions.

/**
* Only show Dev Edition promo if it's enabled (beta channel),
* if it has not been shown before, and it's a locale build
* for `en-US`
*/

Either way i'll rip it out before release.

[Moonchild]

we wouldn't have been looking for Mozilla branding in the platform, only in the application side.

Not just that, we wouldn't have been looking into generic doorhanger code inside the devtools for something like this.

[suzyne]

This is all quite illuminating!

Ignoring the code side of things, I guess at the very least it means there has been a blue Firefox logo hiding somewhere in the Pale Moon source folders?

[Moonchild]

Ignoring the code side of things, I guess at the very least it means there has been a blue Firefox logo hiding somewhere in the Pale Moon source folders?

Yup. And inadvertently built into the binaries:

Code: Select all

chrome://devtools/content/framework/dev-edition-promo/dev-edition-logo.png

[mrnhmath]

The current implementation of devtools is so dogpile that it didn't surprise me that there were some direct trademarked leftovers from Mozilla.

Nuking it in favor of a Jetpack-less incarnation like the one from Firefox 23 is on my research list.

[athenian200]

The current implementation of devtools is so dogpile that it didn't surprise me that there were some direct trademarked leftovers from Mozilla.

Nuking it in favor of a Jetpack-less incarnation like the one from Firefox 23 is on my research list.

Hmm... I'm not sure if I agree with that if it means we lose potentially useful features from the newer DevTools. It seems to work well enough aside from the new ugly coat of paint Mozilla added to it, so I wouldn't be in favor of nuking it unless the replacement can do everything the current version can. Of course, if your implementation just changes the UI to look better, reworks code, and such and leaves all the same functionality/options in place, then I have no objection. But I don't want to lose functionality in DevTools just to have something that looks more like the Firefox 20-29 series if that's the option on the table. It's worth noting that we would need to use them to debug fairly modern things that are being added to the browser in some cases, and we don't really want to make it harder to update DevTools to do that if that winds up being a factor.

It's important not to get too worked up about every remnant of Mozilla's 2017-era decisions left in UXP, what's important is that we're never adopting any more of it. We're a hard fork and we've drawn the line already. I really don't think we need to go back and reverse every single thing that crept into Firefox 52 in 2024 we don't like just to demonstrate that we're standing against modern Mozilla.

It's easy enough to rip out the doorhanger and leave it at that, I don't think we need to go for the nuclear option of getting rid of DevTools or reverting them to a much older version here...

[mrnhmath]

Hmm... I'm not sure if I agree with that if it means we lose potentially useful features from the newer DevTools. It seems to work well enough aside from the new ugly coat of paint Mozilla added to it, so I wouldn't be in favor of nuking it unless the replacement can do everything the current version can. Of course, if your implementation just changes the UI to look better, reworks code, and such and leaves all the same functionality/options in place, then I have no objection. But I don't want to lose functionality in DevTools just to have something that looks more like the Firefox 20-29 series if that's the option on the table.

Personally I have never cared for any of its features beyond basic HTML editing and network monitoring, and I'd imagine it's the same for most of our users.

I just think it would be nice to have something that doesn't crawl to a halt on a 2022 system because it depends on a myriad of dead-on-arrival frameworks that none of us want anything to do with.

[athenian200]

Personally I have never cared for any of its features beyond basic HTML editing and network monitoring, and I'd imagine it's the same for most of our users.

Well, I never really thought of it as a primarily user-facing feature, and it's mostly developer-focused features I would be concerned about losing. So are you saying that such a version of the DevTools would be limited to simple HTML editing and network monitor, and we'd just have to let go of everything else? Or am I misunderstanding?

I guess there's not much point in arguing further until I see what the older version you're proposing looks like and what it can do. I might be worrying about nothing for all I know, I've never seen that version of DevTools.

I just think it would be nice to have something that doesn't crawl to a halt on a 2022 system because it depends on a myriad of dead-on-arrival frameworks that none of us want anything to do with.

Yes, it would be nice if it depended on fewer frameworks, but I'm not content to just use something simpler and older to get that to be the case. I've never been a fan of just carelessly nuking things that don't fit in and adopting simpler, older things. That to me is almost as bad what Mozilla does in the opposite direction. I primarily like older things when they have more features than their current incarnations. Ripping out features to revert to older ways of doing things appeals to me about as much as ripping out features to "streamline" something and make it more modern. I don't know if that makes sense or not.

[mrnhmath]

Well, I never really thought of it as a primarily user-facing feature, and it's mostly developer-focused features I would be concerned about losing. So are you saying that such a version of the DevTools would be limited to simple HTML editing and network monitor, and we'd just have to let go of everything else? Or am I misunderstanding?

It's been a while since I took a look at this subject, but I don't remember the older DevTools being as spartan as one would have imagined. It had much better performance though, and that sparkled my despise for the newer ones.

I think my research would be limited to see what would it take to retrofit it to the platform. I don't care for DevTools as much since I prefer the traditional stuff.

[athenian200]

It's been a while since I took a look at this subject, but I don't remember the older DevTools being as spartan as one would have imagined. It had much better performance though, and that sparkled my despise for the newer ones.

I think my research would be limited to see what would it take to retrofit it to the platform. I don't care for DevTools as much since I prefer the traditional stuff.

Hmm... well, I just looked at the Firefox 23 developer tools out of curiosity, and it seems like it's very similar to what we have in the platform now, at least on the surface? It has the Style Editor for CSS and all that at least.

One major thing I am curious about is whether the older DevTools can inspect the browser chrome (like on Developer Toolbox and all that) the way the new ones can. The thing is... I use that feature on Epyrus a lot to inspect that application's equivalent of browser chrome (whatever that would be called for a mail client) because I'm not very experienced with XUL and JS yet, and not having it would make it harder for me to debug what's going on.

The other issue is that it would need to be taught how to deal with Shadow DOM potentially, while our existing DevTools kind of know how to deal with that because we backported some stuff from Mozilla to make that possible. But yeah, as long as nothing major is broken by this, I'm happy with having more performance and a better aesthetic.

[Moonchild]

Hmm there would be a problem retrofitting old devtools. The older tools are much more limited IIRC and while you may personally not use much of it, others would be. I don't want to lose functionality as a result and going back to mid-20s devtools will definitely remove a whole bunch of useful tools from the inspector at the very least, like being able to trace element-attached JS events. It'd also have to be updated for newly-added CSS properties and values... and shadow dom/shadow trees.
Not being able to inspect cookies, cache, IndexedDB/local storage would be a big step back, and I don't think that was part of the old tools. Other things like GLSL/canvas/webaudio wouldn't be much of a loss, but the storage category i think would be important to have.
If we can come up with a reasonably modernized incarnation of the faster tools then I'd be happy with it, but we'd really have to make sure it's fully usable and reasonably complete for 2024 compared to what we have now.

One major thing I am curious about is whether the older DevTools can inspect the browser chrome

I'm pretty sure it had a chrome inspection option in there.

[mrnhmath]

If we can come up with a reasonably modernized incarnation of the faster tools then I'd be happy with it, but we'd really have to make sure it's fully usable and reasonably complete for 2024 compared to what we have now.

At least the idea is out there for anyone to pick up. I'm way more interested in reviving Venkman... have many memories with it.

[BenFenner]

Personally I have never cared for any of its features beyond basic HTML editing and network monitoring, and I'd imagine it's the same for most of our users.

As a web developer who targets Pale Moon first, I find nearly all of the dev tools indispensable.

[suzyne]

As long as there are the Inspect, Console and Debugger (with breakpoints and viewing variables) panels I am good, but I agree it would be unwise to remove any functionality even if it made the developer tools more responsive, because it is tricky for me to predict what I might need tomorrow, and impossible to say what current and future Pale Moon users might want.

[vannilla]

I use at least 80% of what the devtools provide, if any of you is gathering data on the matter.
And as we know, 80% for someone is not the same 80% for another person.