Closed Bug 790905 Opened 7 years ago Closed 7 years ago
Processing the mozilla
.cfg file fails if the file contains Java Script: "Failed to read the configuration file"
754 bytes, text/plain
1.48 KB, patch
|Details | Diff | Splinter Review|
3.36 KB, patch
|Details | Diff | Splinter Review|
Regression window(m-c) Good: http://hg.mozilla.org/mozilla-central/rev/96287ad60bef Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120910183953 Bad: http://hg.mozilla.org/mozilla-central/rev/d042ad078f43 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120911065552 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=96287ad60bef&tochange=d042ad078f43 Regression window(m-i) Good: http://hg.mozilla.org/integration/mozilla-inbound/rev/c8e5053af5ad Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120911004454 Bad: http://hg.mozilla.org/integration/mozilla-inbound/rev/4f5b4f0ecf01 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/18.0 Firefox/18.0 ID:20120911010554 Pushlog: http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=c8e5053af5ad&tochange=4f5b4f0ecf01
In local build, Last good:382dce79a998 First bad: 1cef36c730eb
Hm, just setting general.config.obscure_value and general.config.filename doesn't seem to cause anything to happen. According to gdb, nsReadConfig::Init is never called (so the observer doesn't get registered). Do I need an extension or something to make this stuff work?
No need add-on. STR 1. Install Firfox to "Installation directory" 2. Copy mozilla.cfg to Installation directory/mozilla.cfg Copy local-settings.js to Installation directory/defaults/pref/local-settings.js 3. Start Firefox
Looks like the fix in bug 776490 wasn't quite right, but continued to work because of dynamic UniversalXPConnect checks, which are now gone. Patch coming up.
This would have caught this bug.
Attachment #661205 - Flags: review?(luke)
defaultPref has been broken all along as well. Any chance this will fix that? https://bugzilla.mozilla.org/show_bug.cgi?id=786875 Also, this will obviously have to be backported to at least 17.
(In reply to Michael Kaply (mkaply) from comment #8) > defaultPref has been broken all along as well. Any chance this will fix that? I'm really not sure. It's sort of an accident that the patch in bug 776490 worked, so it might not have covered all the cases. > Also, this will obviously have to be backported to at least 17. Well, I believe this only broke in 18, right? Though I'm fine to backport this for correctness' sake (especially if it fixes defaultPref).
Comment on attachment 661204 [details] [diff] [review] Make the compartment principal of autoconfig_glob match the principal passed to JS::Evaluate. v1 r=me
Attachment #661204 - Flags: review?(bzbarsky) → review+
Comment on attachment 661205 [details] [diff] [review] Replace no-op principal check with something real. v1 Can we just remove options.principals then? It seems like it only exists to be gotten wrong.
(In reply to Luke Wagner [:luke] from comment #11) > Comment on attachment 661205 [details] [diff] [review] > Replace no-op principal check with something real. v1 > > Can we just remove options.principals then? It seems like it only exists to > be gotten wrong. Eventually yes - I plan to gut a bunch of obsolete security stuff from the js-engine. But at the moment that's more surgery than I'd like to do right now, and I'd like to just land this to ensure that, at the very least, the consumers aren't getting the wrong thing here.
Comment on attachment 661205 [details] [diff] [review] Replace no-op principal check with something real. v1 Excellent.
Attachment #661205 - Flags: review?(luke) → review+
Looks green, modulo one make-check jsapi-test that I fixed. Luke, I took the liberty of carrying over your review on that one: https://hg.mozilla.org/integration/mozilla-inbound/rev/acec40170961#l1.42 - I hope that's ok? Pushed to inbound: remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/ef528ae38f04 remote: https://hg.mozilla.org/integration/mozilla-inbound/rev/acec40170961
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Fine by me. So are JS_(Get|Set)FrameAnnotation going away now? If so, don't forget to zap StackFrame::annotation_ and HAS_ANNOTATION or file a bug on me to do so.
This will need to make Firefox 17 as well so it is in the ESR
Can we get a try build so that mkaply can help us confirm this is fixed.
(In reply to Michael Kaply (mkaply) from comment #18) > This will need to make Firefox 17 as well so it is in the ESR Is it actually broken on 17? I thought that the dynamic UniversalXPConnect checks were saving us there. Anyhow, happy to backport it just to be safe.
(In reply to Michael Kaply (mkaply) from comment #18) > This will need to make Firefox 17 as well so it is in the ESR mkaply - are you definitely hitting this bug on FF17? We can hold on a try build until that's confirmed.
You need to log in before you can comment on or make changes to this bug.