278429 - browser.link.open_newwindow=3 doesn't work in app suite and that pref isn't exposed in UI

Status: RESOLVED INVALID

(SeaMonkey :: Preferences, defect)

Description

[Akkana Peck]

In 1.8a6, links with target=_blank are popping up new windows, even though I
have browser.block.target_new_window=true.

Comment 1

[sairuh (rarely reading bugmail)]

could this be due to the merge of 172962 to the trunk? (referring to bug 172962
comment 218; see also bug 274143 for Camino.)

Comment 2

[Akkana Peck]

I read the bugs sairuh referenced, and a few other bugs mentioned; I see lots of
requests for docs but there's still nothing in the release notes under "new" or
"window".

I tried
user_pref("browser.link.open_newwindow", 1); // OPEN_CURRENTWINDOW
since that seemed like the most obvious pref name and the most obvious idl
symbol, but it didn't help, target=_blank still opens in a new window.

It looks like the relevant code is here:
http://lxr.mozilla.org/seamonkey/source/browser/base/content/browser.js#3184
and the values it uses are here:
http://lxr.mozilla.org/seamonkey/source/dom/public/idl/base/nsIBrowserDOMWindow.idl#52

However, it looks like openURI, if passed aWhere==OPEN_NEWWINDOW, doesn't check
any prefs at all, and immediately proceeds to open up a new window.  If
aWhere==OPEN_DEFAULTWINDOW, then it does check prefs, and might replace aWhere;
the first clause is checking browser.link.open_external, which makes sense, but
then for internal links it checks browser.link.open_newwindow.  So the
browser.link.open_newwindow pref is for links with aWhere ==
nsCI.nsIBrowserDOMWindow.OPEN_DEFAULTWINDOW and aContext != OPEN_EXTERNAL, not
for links with aWhere == OPEN_NEWWINDOW.

What is aWhere?  The only documentation for it in nsIBrowserDOMWindow.idl is
"see possible values described above".  Does it reflect the target=whatever on
the link, or something else?

There's also one other pref that looks like it might be relevant:
browser.link.open_newwindow.restriction.  The only code which uses it is here:
http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#4716
but it baffles me so I can't guess what the right value would be (and do I want
to "divert", "not divert", or "divert with features"?  What are the features?)
So I tried exhaustive search, trying 1 and 2 (default was 0), but in each case a
target=_blank link still opened in a new window.

I'm out of ideas.  Do these prefs actually work?  What do the settings mean?

Comment 3

[Dan M]

Build date? Testcase? Duplicate of one of the other four invalid or duplicate
target_new_window bugs?

Comment 4

[Akkana Peck]

I need a build date for "1.8a6"?  Sorry, I assumed that there was only one
release by that number.  It's "Build ID 2005011116", "Mozilla/5.0 (X11; U; Linux
i686; en-US; rv:1.8a6) Gecko/20050111", from the mozilla.org full installer.

Testcase: I'll attach an html file with a target=_blank link.  I didn't before
because I assumed there were tons of those floating around already.

Dup?  I don't know.  I assume it's related to the bugs sairuh mentioned, and
some of the others linked therefrom, but I didn't see a bug that specifically
covers this issue in the suite.  There may well be a bug open on this issue
which I haven't found.

Comment 5

[Akkana Peck]

Attachment: test case

Set the pref browser.block.target_new_window to true, so that new windows
should be blocked, then click on the "target _blank" link.  A new window pops
up.

Comment 6

[sairuh (rarely reading bugmail)]

related to (or dup) of bug 78037?

Comment 7

[Akkana Peck]

Bug 78037 seems to be on exposing the pref in the prefs UI, though the summary
doesn't make that clear.  The pref itself has been in place for years and
working fine, until now.

Comment 8

[Dan M]

OK, the actual 1.8a6 build. (When *I* say 1.8a6 build, I generally mean
something later than the official release, and currently there is some suspicion
that something of this regressed in 20050112 builds.) And I wanted to see a
testcase to see if you were doing something tricky. Basically I was curious to
see whether this was some variant of bug 278143.

But I see none of that applies. browser.block.target_new_window is now obsolete.
You want browser.link.open_newwindow. See
http://www.mozilla.org/unix/customizing.html. See also bug 276335 which by the
way is the most obvious choice of bugs to dupe this one against.

Yes the Aviary branch landing damaged the Suite's single window mode
capabilities. However the piece of SWM that covers the old target_new_window is
functional in the Suite on the trunk. The new pref works for me using the
official WinXP 1.8a6 build.

Comment 9

[Akkana Peck]

Yikes!  Playing around some more with the value of that preference, I discovered
two things: (1) When set to 1, I wasn't seeing any change before because the
test page has to be reloaded after changing the pref, in order to see any
difference in behavior, and (2) I had been setting the pref in user.js, which is
being completely ignored.

My user.js line looked like this:
user_pref("browser.link.open_newwindow", 1);
yet when I restarted mozilla, visited about:config and limited to "newwindow",
the setting was still 2, the default.

Is there a known regression reading user.js?  I didn't find anything searching
bugzilla.

Anyway, it looks like when I set browser.link.open_newwindow to 1 in
about:config, then hit reload on the test page, the link opens in the current
window, like the old pref.  If I set the pref to 3, though, it still opens in a
new window, not a new tab (same thing if it's set to 2).  What am I missing?

BTW, I don't suppose there's any way to have target=xxx open in the current
window, but window.open open in a new tab, by any chance?  I'm trying to grok
what browser.link.open_newwindow.restriction does from the terse comment in
customizing.html; and that page doesn't mention browser.link.open_newwindow=1 or
2 at all.  I can update that page if I can find out what these prefs actually do
and what the legal values are.

Comment 10

[Dan M]

> (1) ...I wasn't seeing any change before because the
> test page has to be reloaded after changing the pref

That's odd. The old code, the code that used the obsolete pref, required the
page to be reloaded before a change would take effect. The new code does not
cache the pref and indeed, changes take effect immediately in my testing. I'm
using Windows Firefox but the code is in Docshell, where it should be ignorant
about platforms and clients.

> Is there a known regression reading user.js?

None that I know of. user.js prefs behave as expected for me, even with this pref.

> If I set the pref to 3, though, it still opens in a
> new window, not a new tab

That's likely part of the damage to the Suite from the Aviary branch landing
that hasn't been sorted out.

> ...any way to have target=xxx open in the current
> window, but window.open open in a new tab...?

We don't provide any way to distinguish behaviour at that level.

> I can update [customizing.html] if I can find out what these prefs actually do
> and what the legal values are.

I would have added it myself but it seemed out of place to me in a document that
lists favorite settings but doesn't enumerate them. Perhaps
http://www.mozilla.org/support/firefox/tips would have been a better document to
name.

---

So where are we? Is this a bug or not? I don't understand the problem you're
having with pref cacheing. But it seems to me that outside of that issue, which
would be a separate bug anyway, we've settled that this is in fact a duplicate
of bug 276335. There are also other bugs like bug 276808 and bug 278867. Really
I expect the only part that does work well is what was once target_new_window.

Comment 11

[Akkana Peck]

Perhaps it's a dup of 278867, though someone searching for the bug would never
find that one, and it's assigned to nobody.

What about the release notes?  There's still no mention of this popular pref's
replacement in the release notes, nor is there documentation anywhere of the
legal values for the new prefs or how to duplicate the old behavior.  The
closest thing to documentation is a line in customizing.html, describing a
setting which doesn't actually work (browser.link.open_newwindow=3).  Is there
already a bug covering these documentation issues?  That's definitely part of
this bug: "How can people who used the old pref find out what they need to change?"

> Perhaps
> http://www.mozilla.org/support/firefox/tips would have been a better
> document to name.

I'm not seeing any documentation of the open_newwindow options there either,
though it does have information about the values of open_newwindow.restriction.

I'll investigate the user.js problem and probably file a separate bug.

Comment 12

[Dan M]

Any relation of this bug to 278667 would be as a dependency, not a duplicate. I
can't find a distinction between this bug and 276335, now that we've determined
they're the same, disregarding some ancillary issues that might want their own bugs.

browser.link.open_newwindow is supposed to be surfaced in the actual UI. Values
are from nsIBrowserDOMWindow, though 0 is nonsensical as a pref setting. The
...restriction pref is in contrast a geek tweak that's not necessarily supposed
to be in the UI, and so it lives happily in the tips document. 1.8a6 release
notes should probably have brought this up though, pending a UI that would make
the grungy details moot.

> [customizing.html]... describing a
> setting which doesn't actually work (browser.link.open_newwindow=3

Good point. It does work in Firefox, though.

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

too late for 1.8b1, transferring request to 1.8b2

Comment 14

[ChrisX]

All I can say is that browser.block.target_new_window worked in 1.8a4 on the
Mac. When I went to 1.8b yesterday, I immediately noticed the broken function. I
would very much request this to be fixed in 1.8b2 because I am so much used to
tabbed browsing by now, and creating new windows is irritating when you don't
expect it, especially on the Mac where you don't have a startbar to switch
between them. Additionally, the new window is lowered, with the result that the
 status bar at the bottom is below the edge of the display (1ß24x768) and thus
invisible. 

Comment 15

[ChrisX]

I am sorry, I didn't read the comments closely enough.
browser.link.open.newwindow set to 1 in about:config actually restores the
functionality, and also sticks after quitting the browser. Problem solved (or
workedaround); but it's confusing that browser.block.target_new_window is still
present in about:config although it's obsolete (i.e. does nothing anymore).

Comment 16

[Robert Kaiser]

We're not holding an alpha release for a non-working hidden pref, I think. Would
be nice to see a patch though...

Comment 17

[Akkana Peck]

I think this summary reflects the remaining two problems as discussed in the comments.

Comment 18

[Serge Gautherie (:sgautherie)]

(Filter "spam" on 'prefs-nobody-20080612'.)

Comment 19

[Philip Chee]

browser.block.target_new_window is not present in comm-central