On 17/01/2018 00:01, Daniel Veditz wrote:
On Fri, Jan 12, 2018 at 2:12 PM, Gijs Kruitbosch <gijskruitbo...@gmail.com>
wrote:
the most likely group of people to have enabled this (given 0 public
reports on breakage so far, as far as I'm aware) are people on ESR or
otherwise in enterprise environments
Or those trying to run multi-file testcases packaged as a ZIP archive on
bugzilla (Hi!) without having to run a localhost server for it. Especially
handy when the testcase was demonstrating something specifically about our
handling of https pages.
Yes, I'm aware of this issue and mentioned it on the bug. You're not the
only one who does this.
Does removing this let us remove a good chunk of code?
I am led to believe that the answer to this is 'yes'.
I'm glad it's
disabled by default (attack surface reduction) but afaik we still have to
support jar: internally.
At this point I am actually not aware of any substantial consumers who
rely on jar: explicitly internally through gecko (Android has some
consumers that go through java, but that's not the same, see comments on
the bug). chrome: and resource: of course do so implicitly, but we
don't, as a rule, e.g. load documents with jar: URIs. So "support" is
relative.
It may be just me using this at this point so if
we can kill a bunch of stuff that's a win, but if you're just taking away
the pref is that worth it?
Even if it was mostly the pref, it removes complexity and edgecases, and
I think that's something we should push for as we add complexity
elsewhere, to keep things reasonable, as it were. :-)
If "archives on bugzilla" is a significant thing, we should push for
better support from bugzilla. (Also for other formats like gz, bz2, rar,
etc. which jar: doesn't support!)
~ Gijs
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
