In 1.8a6, links with target=_blank are popping up new windows, even though I have browser.block.target_new_window=true.
could this be due to the merge of 172962 to the trunk? (referring to bug 172962 comment 218; see also bug 274143 for Camino.)
Component: XP Miscellany → Preferences
Product: Core → Mozilla Application Suite
Assignee: nobody → prefs
QA Contact: brendan
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?
Build date? Testcase? Duplicate of one of the other four invalid or duplicate target_new_window bugs?
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.
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.
related to (or dup) of bug 78037?
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.
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.
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.
> (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.
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.
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.
too late for 1.8b1, transferring request to 1.8b2
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.
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).
We're not holding an alpha release for a non-working hidden pref, I think. Would be nice to see a patch though...
Flags: blocking-seamonkey1.0a? → blocking-seamonkey1.0a-
Whiteboard: needs new summary since that pref no longer exists
I think this summary reflects the remaining two problems as discussed in the comments.
Summary: browser.block.target_new_window no longer prevents new windows → browser.link.open_newwindow=3 doesn't work in app suite and that pref isn't exposed in UI
Whiteboard: needs new summary since that pref no longer exists
(Filter "spam" on 'prefs-nobody-20080612'.)
Assignee: prefs → nobody
QA Contact: prefs
browser.block.target_new_window is not present in comm-central
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.