287086 - Move browser.link.* prefs out of all.js and ensure they are not required by all apps

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Mike Connor [:mconnor]]

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.

Comment 1

[Mike Connor [:mconnor]]

Attachment: patch to ensure all cases fall back, and move the prefs to the appropriate app locations

This does not involve any pref changes, just physically moving them for now,
and a one-liner in nsGlobalWindow.cpp

Comment 2

[Johnny Stenback (:jst)]

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

Comment 3

[Mike Connor [:mconnor]]

Attachment: with all.js removal+fancier comments for SM+jst's review comment

Comment 4

[[e-mail]]

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.

Comment 5

[Mike Connor [:mconnor]]

checked in.  Thanks for the reviews!

Comment 6

[Hiro]

Refer to mozilla/modules/libpref/src/init/all.js for Camino. 
Where does an initial value for Camino move?

Comment 7

[Mike Connor [:mconnor]]

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.

Comment 8

[Hiro]

(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.