Deprecating the chrome and resource protocols

[Dave Townsend]

Hi all. I've written up a proposal for moving us away from the confusing chrome and resource URLs that we use internally to reference files in the build in favour of a new simpler URL scheme based on the file's path in the source tree. This will make it clearer to developers where code is coming from and open up new possibilities for linting, intellisense in editors, and other automated tools.

While it doesn't cover completely removing the chrome and resource protocol it does cover removing the majority of our uses of them (HTML, CSS and JavaScript files). The first few stages detailed in the proposal have already been prototyped and so I'm looking for any comments or concerns on the plan before we begin to move forwards.

https://docs.google.com/document/d/1dZXsWmFxQ8y_EofCrD_a5DIZUmmAjIhR1VwVTEabawE/edit#

[Dave Townsend]

Publicly viewable link for non-employees: https://docs.google.com/document/d/e/2PACX-1vS0E2ANhH7eKkA-LscLudWLguseklE_003b_6nzLGViSYn7z-KS2aHwNpfGUGpRWZZBFBJXS5xY48by/pub

[Sam Foster]

I was just reading the (now removed?) docs http://www.devdoc.net/web/developer.mozilla.org/en-US/docs/Web/CSS/-moz-context-properties.html for -moz-context-properties, and I don't know to what extent that content remains true, but it says our support for `-moz-context-properties` is tied to the chrome: and resource: schemes. Would we need a new way to gate this kind of feature or just port that directly over to moz-src:?

/sfoster

--
You received this message because you are subscribed to the Google Groups "firef...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firefox-dev...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/firefox-dev/CAPMxTNpqfgq0Ex%3DM4XA1iw62uBff0r03gmcASp9%2BuPoxMqyYQA%40mail.gmail.com.

[Daniel Veditz]

We're trying to get rid of the non-standard -moz-context in favor of a newer standard feature (bug 1782815), but yes, to the extent we still need "chrome-only" features they would be supported by the new thing. This is the first I've heard of replacing chrome:// but I imagine the implementation is mostly a new name mapping. In this particular case we'd have to add the new scheme to URLExtraData::ChromeRulesEnabled(), but hopefully most such places are written to check protocol flags on the URL instead and will "just work" when we add new schemes (which was the point of having protocol flags).

-Dan Veditz

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/firefox-dev/CA%2BOpn%3Djpw62YqbRxBPtM62m9U4Ayah-KJWk%3Dhgbjk6FRzx3rUA%40mail.gmail.com.