Closed Bug 1426763 Opened 7 years ago Closed 6 years ago

[meta] Remove XUL overlays

Categories

(Core :: XUL, enhancement, P5)

Product:
Core
Component:
XUL
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bdahl, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: dev-doc-complete, meta)

Depends on: 1434016
Depends on: 1434018
Depends on: 1434046
Depends on: 1434050
Depends on: 1434077
Depends on: 1434151
Depends on: 1434381
Depends on: 1435437
Depends on: 1439766
Depends on: 1441378
Depends on: 1442302
Depends on: 1442829
Depends on: 1443901
Depends on: 1443971
Depends on: 1444228
See Also: → 1444468
So the overlays are actually useful, the functionality is just faked via more includes and preprocessing. Something that should actually be removed where possible. I don't understand the direction. And of course addon authors do not have the option of preprocessing...
Blocks: post-57-api-changes
See Also: → 1444685
(In reply to :aceman from comment #1)
> So the overlays are actually useful, the functionality is just faked via
> more includes and preprocessing. Something that should actually be removed
> where possible.

I think we'll continue to iterate and potentially remove/reduce the number of includes here further, but certainly while we're untangling the current hodge-podge of overlays #includes are a useful way to not touch too much code and be able to get rid of the current consumers. Given that almost all the documents we're introducing these into already had existing preprocessor requirements, this doesn't really make the include/preprocessing situation any worse.

> I don't understand the direction.

Did you not read the document linked in comment #0? It starts off by explaining the reasons behind wanting to get rid of overlays.

> And of course addon
> authors do not have the option of preprocessing...

Webextensions can't use overlays either, and before that bootstrapped add-ons couldn't use them (and SDK add-ons wouldn't use them) in their manifests, either, because there's no concept of 'unloading' overlays. So it's not like we're removing something which was in common use until just a few months ago - the overlay system has been out of regular use by add-ons for years. Only non-restart-compatible add-ons used them. Even the in-tree XUL add-ons that I'm aware of don't use them, and instead dynamically add/remove content using the window manager or CustomizableUI to deal with new (browser) windows being created/destroyed.

Really, if we intend to move away from XUL, towards HTML and something less alien, more spec-compliant, then idiosyncratic things like overlays (that nobody unfamiliar with XUL knows about or understands without considerable explanation) need to go. This will also allow significant simplification of the XUL document loading code (as the document in comment #0 points out), which is currently complicated because various bits of the document are pulled in via overlays (which can then themselves pull in more overlays, remove elements, etc. etc.). It is also already uncovering code quality issues and leading to simpler code in many of the cases.
Following these discussions and references it's unclear for me as an addon author what the impact for the addon code will be. 
Or better asking these points:

-- will all functionality be removed to load and execute Overlays? If yes, classic (non-restartless) extensions will not work anymore without massive recoding. Right?

-- there are two terms I need more background for: 'inline' and 'pre-processing'. 
**  'inline' seems to be clear that way, a XUL code modification should not take place anymore, all such has to be directly included with the 'base' XUL. That way the 're-use' of XUL will be gone, more coding required.
**  'pre-processing' what does that mean? With addons overlay loading all required js/css/dtd/and such will be handled. Today if an addon overlay loads another overlay that one is responsible to get it's stuff in place, again loading js/css/dtd/and such. With no more overlay loading those elements need to be processed by the first overlay --- named as 'pre-processing. Right?

A final open point after removing overlays: how can addons live at all? Or better how would they be started/involved? Which method, call etc?
(In reply to Günter from comment #3)
> Following these discussions and references it's unclear for me as an addon
> author what the impact for the addon code will be. 

No add-ons currently supported on current Firefox release (non-ESR52) versions will be impacted at all...

> Or better asking these points:
> 
> -- will all functionality be removed to load and execute Overlays? If yes,

Yes.

> classic (non-restartless) extensions will not work anymore without massive
> recoding. Right?

They already don't work...

> -- there are two terms I need more background for: 'inline' and
> 'pre-processing'. 
> **  'inline' seems to be clear that way, a XUL code modification should not
> take place anymore, all such has to be directly included with the 'base'
> XUL. That way the 're-use' of XUL will be gone, more coding required.

You can re-use things the same way you reuse them in other JS environments, either by introducing a packaging step or my setting up your code so that the inclusion of new UI is part of a utility function that you can call with various parameters and/or from different places.

> **  'pre-processing' what does that mean? With addons overlay loading all
> required js/css/dtd/and such will be handled. Today if an addon overlay
> loads another overlay that one is responsible to get it's stuff in place,
> again loading js/css/dtd/and such. With no more overlay loading those
> elements need to be processed by the first overlay --- named as
> 'pre-processing. Right?

No. Pre-processing in this context is talking about the preprocessor that the Firefox / mozilla-central build system uses. It is one way of doing the packaging step I mentioned earlier.

> A final open point after removing overlays: how can addons live at all? Or
> better how would they be started/involved? Which method, call etc?

This has been possible ever since bootstrapped add-ons, 7-8 years ago, per history here: https://developer.mozilla.org/en-US/docs/Archive/Add-ons/Bootstrapped_extensions$history?page=10 . See also e.g. https://blog.mozilla.org/addons/2012/07/12/why-you-should-make-your-add-on-restartless/ . Here's an old tutorial on making your add-on restartless: https://developer.mozilla.org/en-US/docs/Archive/Add-ons/How_to_convert_an_overlay_extension_to_restartless . No guarantees about correctness etc. at this point. It might be easier to just rewrite as a webextension.

Note that this is really not the best place to have this discussion. If you have follow-up questions, please use a relevant mailing list instead.
Hi all. I am very certain everyone is aware, but I'd like to remind that while this is a Core/XUL issue, Gecko is mainly driven by Firefox. While it is fair to inquire about the motivation around use of the preprocessor vs other approaches, we should keep any discussion around effects on legacy add-ons out of this bug.

For Thunderbird, there is a possibility that we can replicate the xul overlay functionality in JS, and I think this is the most sensible short term solution. Discussion on this topic should occur in a different bug. I know the emotions are high because xul overlays has been a core feature for as long as I remember, but we should make sure to keep discussion focused.

Thank you everyone on the Gecko team for removing some of the technical debt and the enormous work in getting rid of XUL, and thank you Thunderbird team for holding up the fort while we make some headway on many of the same issues.
Depends on: 1444973
Depends on: 1447354
Depends on: 1448162
Priority: -- → P5
Depends on: 1449791
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Are these pages truly removed or moved to some kind of archive as it is done with many other outdated pages? The later would be nicer to better understand old code.
(In reply to Croydon from comment #11)
> (In reply to Chris Mills (Mozilla, MDN editor) [:cmills] from comment #10)
> > I’ve had a go at removing overlays from MDN. I’ve removed the following
> > pages:
> > 
> > https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/overlay
> > https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/Overlays
> > https://developer.mozilla.org/en-US/docs/Web/API/Document/loadOverlay
> > 
> > And removed any mention of them from these pages (I think):
> > 
> > https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL
> > https://developer.mozilla.org/en-US/docs/Web/API/Document/loadOverlay
> > https://developer.mozilla.org/en-US/docs/Mozilla/Chrome_Registration
> > 
> > Let me know if you spot any others. Thanks!
> 
> Are these pages truly removed or moved to some kind of archive as it is done
> with many other outdated pages? The later would be nicer to better
> understand old code.

They were removed from MDN 😔
You need to log in before you can comment on or make changes to this bug.