Closed
Bug 287086
Opened 19 years ago
Closed 19 years ago
Move browser.link.* prefs out of all.js and ensure they are not required by all apps
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: mconnor, Assigned: mconnor)
References
Details
Attachments
(1 file, 1 obsolete file)
3.15 KB,
patch
|
neil
:
superreview+
|
Details | Diff | Splinter Review |
The initial reason that these prefs lived in all.js was apparently because core code depended on them and there were concerns about handling them if not defined. Having looked at the code in question, other than one location, that isn't the case at this point. There are safe fallbacks if the prefs are undefined, except for the case which I'll attach a patch for. These prefs should not live in all.js, as they are essentially meaningless to all non-browser apps running on the Mozilla platform/xulrunner. Patch coming up.
Assignee | ||
Comment 1•19 years ago
|
||
This does not involve any pref changes, just physically moving them for now, and a one-liner in nsGlobalWindow.cpp
Assignee: general → mconnor
Status: NEW → ASSIGNED
Attachment #178133 -
Flags: superreview?(bzbarsky)
Attachment #178133 -
Flags: review?(jst)
Comment 2•19 years ago
|
||
Comment on attachment 178133 [details] [diff] [review] patch to ensure all cases fall back, and move the prefs to the appropriate app locations - In dom/src/base/nsGlobalWindow.cpp: containerPref=nsContentUtils::GetIntPref("browser.link.open_newwindow", nsIBrowserDOMWindow::OPEN_NEWWINDOW); PRInt32 restrictionPref = nsContentUtils::GetIntPref( - "browser.link.open_newwindow.restriction"); + "browser.link.open_newwindow.restriction", 0); This changes nothing, the default will be 0 even w/o this change (see the declaration of GetIntPref() in nsContentUtils.h), so no need to make this change. r=jst
Attachment #178133 -
Flags: review?(jst) → review+
Assignee | ||
Comment 3•19 years ago
|
||
Attachment #178133 -
Attachment is obsolete: true
Attachment #178175 -
Flags: superreview?(neil.parkwaycc.co.uk)
Assignee | ||
Updated•19 years ago
|
Attachment #178133 -
Flags: superreview?(bzbarsky)
Comment 4•19 years ago
|
||
Comment on attachment 178175 [details] [diff] [review] with all.js removal+fancier comments for SM+jst's review comment sr=me if you remove the "Firefox only" part of the comment plus fix the doubled blank line.
Attachment #178175 -
Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Assignee | ||
Comment 5•19 years ago
|
||
checked in. Thanks for the reviews!
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Refer to mozilla/modules/libpref/src/init/all.js for Camino. Where does an initial value for Camino move?
Assignee | ||
Comment 7•19 years ago
|
||
I can't find any reference to Camino UI using these prefs. If they do, in fact, use them in some way I'm unaware of, and the default fallback values aren't acceptable, then http://lxr.mozilla.org/mozilla/source/camino/resources/application/all-camino.js seems to be where camino-specific prefs live.
(In reply to comment #7) > I can't find any reference to Camino UI using these prefs. Certainly, it is not in Preference UI of Camino. However, browser.link.* It works by customizing the parameter as well as Firefox. Therefore, some influences might go out to Tab Browsing when an initial value is lost.
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•