Hey Axel, Sorry for the slow response.
On Mon, May 9, 2016 at 6:06 PM, Axel Hecht <a...@mozilla.com> wrote: > Hi, > > if we'd move all the fennec-specific chrome:// urls from chrome://browser/ > to chrome://mobile/, would that have a massive impact? > I can't see any reason this would be a big problem. > I guess the biggest question is about the impact on add-ons? > We could check the add-ons MXR to see how many add-ons are actually using these. I'd like for web extensions to be the future of mobile add-ons, so I'm okay with dropping support for add-ons accessing or overriding chrome:// resources, as long as we have a migration plan for anybody is who using that ability right now. > This is really only about chrome:// urls. This doesn't have impact on > where files are in mozilla-central, nor where they're in the omni.ja. But > anything external that'd rely on finding > chrome://browser/skin/images/scrubber.svg or locales, content, would break. > > Background: > > We have tons of problems with chrome overrides in the tree, both in > desktop and mobile. The problem is amplified by fennec sharing a URL space > with desktop, pretending to do the same thing, but totally not doing > anything remotely similar. > > The chrome overrides are a big hurdle in finding out if our l10n setup is > sane. I filed > > https://bugzilla.mozilla.org/show_bug.cgi?id=1255382 and > > https://bugzilla.mozilla.org/show_bug.cgi?id=1255404 > > on some of the more scary ways in which we're broken right now. > > These problems are part of our problem space that we don't have tests that > ensure that the strings we have in our repos actually correspond to our > code. Which is what I'm working on. Which I think is a key blocker to get > to the "one repo per locale for all channels" plan. > IMO a reliable l10n process takes priority over add-on support on mobile, so I'm in support of you doing whatever you need to do to make the situation better. We would need to update the client code where we access these resources ourselves, but I assume that wouldn't be too hard. I do worry about regressions, since our testing story is bad here, but that's not a reason to avoid change. We should just make sure we have a good testing plan in place. Margaret > > Axel > > _______________________________________________ > mobile-firefox-dev mailing list > mobile-firefox-dev@mozilla.org > https://mail.mozilla.org/listinfo/mobile-firefox-dev >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev
