Things which are not browsers still need to display what Firefox displays in about:license (bug 339117, bug 343544), but need to be able to open a local file in the user's default browser. However (bug 325224, bug aboutprotocolsucks), relative links to fragment identifiers don't work in about: URIs, so in license.html we have some links of the form about:license#mpl, which in a local file may coincidently work, or may return something slightly or extremely wrong (like the top of a completely different document in IceWeasel's about:license), or may not be functioning links at all, and some links of the form #exhibit-a that work fine in a local file, but are invisible in about:license. There are two alternatives: fix toolkit/content/license.html, by removing the about:license's that bug 325224 added and instead adding them with script when it's called from about:license, and letting consumer apps decide whether to jar it up or just copy it to their app dir, or, fork it, leaving "toolkit"/content/license.html as Firefox's, and scattering copies throughout the tree that anyone who might take #section-3.3 seriously will need to keep chasing down. Unfortunately, since Thunderbird and Sunbird still need to release off 1.8.1.x, fixing it right means taking a change that will affect Firefox 2.0.0.x (for the better, since it will reveal thirty-odd hidden links, in a rarely-seen page); if it's fixed trunk-only, Thunderbird would probably do a branch-only fork, and Sunbird, which still loves trunk-branch sync, would probably fork on the trunk, and then maybe remember to unfork at some point. Or not.

(I realize this won't ever block a specific 1.8.1.x, but it's the only knob I get to twiddle for wanted1.8.1.x)

Not blocking, but marking wanted so it stays on our radar. Also, not sure if this would block TB2, but nominated anyway. If you can get the reviews and ask for approvals soon, we might be able to get this in sooner than later.

Comment on attachment 252300 [details] [diff] [review] Fix v.1 r=gerv. Gerv

We'll probably need to nominate this for 1.8.1.3 now (i think it's too late for 1.8.1.2 since it effects toolkit and firefox).

You could move |if (location.protocol == "about:"| from both correctSpelling() and correctFragments() to fixup(). > letting consumer apps decide whether to jar it up or just copy it to their app dir Since jars are not compressed, all apps should copy the file to the app dir. In fact, Firefox already copies mozilla/LICENSE (http://lxr.mozilla.org/mozilla/source/LICENSE) to its app dir: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/app/Makefile.in&rev=1.121&mark=390#389 LICENSE is the text of the MPL 1.1, which is contained in license.html as well. So I'd suggest to copy license.html to the app dir instead of LICENSE. Another question (and another bug) is whether to move mozilla/toolkit/content/license.html to mozilla/license.html and remove LICENSE.

Unrotted; one about:-check, thanks. Please do cc me if you file bugs on the rest of comment 6, which are good points (whee, for a while /LICENSE was just "see toolkit/content/license.html" which wouldn't be too useful in a built Firefox app dir), but are not this "need to land on the branch before Tb 2.0 without disturbing Fx 2.0.0.3 any more than absolutely necessary" bug.

Comment on attachment 254779 [details] [diff] [review] Fix v.2 How quickly I forget: XPath lived in extensions/ in 1.8, so I can't go making internal links in the license depend on something that can be turned off in a .mozconfig. Two weeks or less to prevent Tb having to fork, and I'm more than open to new ideas...

So you could either make Thunderbird build transformiix by default on the 1.8 branch. Or you could replace your xpath code by DOM methods like document.getElementsByTagName("a"); http://developer.mozilla.org/en/docs/DOM:document.getElementsByTagName

Having Tb without XPath isn't a problem for me, I only need it for the about: case - what I need is what we have on the trunk but not 1.8 for Firefox, no possible way to build a Firefox that doesn't have XPath. I guess you're right about getElementsByTagName - I've been avoiding it because it's rumored to be on the slow side, but this isn't exactly perf-critical.

So, with cheap |new Date()| instrumentation, I'm seeing times ~65 milliseconds on my slowest machine. For a page that takes a couple hours to read, that doesn't seem too terrible.

Is the xpath code faster? I guess you don't need to worry about the 1.8 branch anymore since bug 339117 is fixed.

Phil, I'm pulling this off the tb2 blocker list since you landed 339117 for us on the branch.

Phil: Is this bug now about unforking license.html? Gerv

For the next ~2 weeks, until Sunbird's code freeze, it's still about what it's about. Then, it'll be "make it possible to unfork license.html," trunk-only, with two dependent bugs for Tb and Sb. Or, since I can't unset the branch flags myself, maybe I'll wontfix it and start fresh, depending on how crabby I'm feeling at the time.

Bug 368091 wound up taking this over.