Sweet, thank you for your support.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1272494 to get this
on track, including a push-to-try of my pretty ad-hoc local patch to
change all those URLs.
Axel
On 12/05/16 15:20, Margaret Leibovic wrote:
Hey Axel,
Sorry for the slow response.
On Mon, May 9, 2016 at 6:06 PM, Axel Hecht <a...@mozilla.com
<mailto: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 <mailto: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
