338777 - Single Window Mode: allow javascript windows with size assigned to open as a new window

Status: RESOLVED FIXED

(Camino Graveyard :: General, defect)

Description

[philippe (part-time)]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.9a1) Gecko/20060521 Camino/1.2+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.9a1) Gecko/20060521 Camino/1.2+

bug 274143 makes Single Window mode working in Camino.
This makes all 'new window' links open in a new tab, or the same tab, depends on how the hidden pref is set.

This also blocks javascript popups to go to a new tab (window.open with size assigned). Firefox has a pref (hidden) to allow those to go through
user_pref("browser.link.open_newwindow.restriction", 2);
(2 is the default value, allows those to go open as a *new* window).

The lack of this causes problems for some CMS systems or message boards and forums, where this is used to open 'help' windows (amongst them on the mozillazine.org forums - add Smilies feature, etc.  when replying to topics).


Reproducible: Always

Comment 1

[philippe (part-time)]

Attachment: html test file

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Confirming; at the very least, we should honor the browser.link.open_newwindow.restriction pref; we might also consider having it be set to 2 when someone enables SWM (for the reasons philippe mentions, which are the reasons Fx has that default, iirc).

I like redirecting those window 90% of the time, but it does break some sites and it will bother people....

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

*** Bug 346136 has been marked as a duplicate of this bug. ***

Comment 4

[philippe (part-time)]

Mike Pinkerton has landed a patch (with no bug number) that appears to fix most of this, at least based on a quick round of testing with Trunk Version 2006081120 (1.2+).
http://tinderbox.mozilla.org/bonsai/cvsquery.cgi?treeid=default&module=Camino&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-08-11+17%3A00%3A00&maxdate=2006-08-11+19%3A00%3A00&cvsroot=%2Fcvsroot

Comment 5

[Samuel Sidler (old account; do not CC)]

(In reply to comment #4)
> Mike Pinkerton has landed a patch (with no bug number) that appears to fix most
> of this, at least based on a quick round of testing with Trunk Version
> 2006081120 (1.2+).

When you say "most", what do you notice as missing? (I haven't at all tested, btw.)

Comment 6

[philippe (part-time)]

(In reply to comment #5)

> When you say "most", what do you notice as missing? (I haven't at all tested,
> btw.)
> 

I said 'most' because I only did a *quick* round of testing on a couple of the sites that I coded (where I have user-triggered pop-up windows), and accessing a couple of CMS that use this feature (like Textpattern). All of them behave as expected (new window pops up in front).

Comment 7

[Mike Pinkerton (not reading bugmail)]

yes, sorry, i didn't know there was a bug. ben was bitching at me about it, and you know how he gets...

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

"Most" meaning we don't redirect *any* window.open calls anymore, regardless of whether the call specifies chrome or size, *and* we *still* don't honor the pref like we should.


To keep pink happy, I've filed bug 348423 on doing what we should have done from day 1 rather than reopen this :P