274143 - (caminoSWM) Fix "single-window mode" prefs

Status: VERIFIED FIXED

(Camino Graveyard :: Tabbed Browsing, defect)

Description

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

Previously, Camino 0.8+ honored Mozilla prefs 
user_pref("browser.block.target_new_window", true);
user_pref("browser.always_reuse_window", true);
to create a pseudo-single window mode.

Merging aviary onto the trunk eliminated those prefs from Gecko and replaced
them with various browser.link prefs (20041207; bug 172962 comment 211).  Most
of the browser.link prefs don't work in Camino, however (the one setting to the
one pref that appears to correspond to the two above does); I assume there's
something that ties the underlying preference into actual behavior in Camino. 

It would be nice to fully implement these new options, at least as hidden prefs,
to be on par with Firefox and SeaMonkey (and perhaps add a UI for the less
esoteric of the settings).

Comment 1

[Mike Pinkerton (not reading bugmail)]

something to investigate for sure to make sure nothing regressed.

Comment 2

[Dan M]

On the trunk, single window mode needs some application level help. SWM assumes
that it can work its way up to the outermost DOM window of any browser and find
an nsIDOMChromeWindow from which it can get a working nsIBrowserDOMWindow
object. I'm guessing this requirement caught Camino by surprise.

Comment 3

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

I just found that Simon W. had long ago filed a bug for a GUI for part of these
prefs, so making this bug block that one.

Comment 4

[Josh Aas]

not an 0.9 blocker

Comment 5

[Ricky]

Single window mode should be enabled in future releases. Thank you.

Comment 6

[Wevah (Nate Weaver)]

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

Comment 7

[Simon Fraser [no longer active]]

(In reply to comment #2)
> On the trunk, single window mode needs some application level help. SWM assumes
> that it can work its way up to the outermost DOM window of any browser and find
> an nsIDOMChromeWindow from which it can get a working nsIBrowserDOMWindow
> object. I'm guessing this requirement caught Camino by surprise.

That doesn't sound very embedding-friendly.

Comment 8

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

(In reply to comment #7)
> That doesn't sound very embedding-friendly.

I don't think Dan M or anyone else from the Aviary bug is cc'd here, so cc'ing
Dan M....

Comment 9

[Hiro]

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

Comment 10

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

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

Comment 11

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

To get this in a future version of Camino, what has to happen?  Does
single-window mode have to be fundamentally re-engineered to work with embedding
apps?  If so, is that something that needs to be pushed in the Gecko 1.9 alpha
cycle so that SWM has a chance of making Camino 1.1?

Comment 12

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

Simon, Mike, as Smokey asked in comment 11, what has to happen to make this work?

Comment 13

[Mike Pinkerton (not reading bugmail)]

a lot, we cannot do this for 1.0

Comment 14

[Chris Lawson (gone)]

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

Comment 15

[Chris Lawson (gone)]

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

Comment 16

[Chris Lawson (gone)]

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

Comment 17

[Yuan Qi]

Make sure you test Gmail and the Developer links on Download.com software entry pages as both seemed to be tricky cases wrt single-window mode.

BTW, Bug 323810 has been fixed on 1.8.1, so do we have half of our problems solved?

Comment 18

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

(In reply to comment #17)
> BTW, Bug 323810 has been fixed on 1.8.1, so do we have half of our problems
> solved?
> 

No, it hasn't. It's awaiting approval.

Comment 19

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

Bug 323810 has now landed on the 1.8 branch.  According to the folks in the forum on the trunk, the changes in bug 323810 break the one part of SWM that worked in Camino after the avaiary-landing (and had worked since time immemorial), so we now have no working way to stop the spawing of new windows.

Moving this back to 1.1 because if we don't fix it, our behavior will be a regression from 1.0.

Comment 20

[Stuart Morgan]

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

Comment 21

[Chris Lawson (gone)]

Tweaking summary, bumping severity to major, adding regression keyword.

We need some help on this one, so if anyone on the cc list has some ideas, please feel free... ;)

cl

Comment 22

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

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

Comment 23

[Chris Lawson (gone)]

This should block 1.1, because without a fix, we're *really* broken.

cl

Comment 24

[[e-mail]]

Attachment: Simple "single-sindow mode" testcase

Simple testcase with two links, one with target="_blank" and one with target="_new".
I tested using a clean profile with the following string in my prefs.js: user_pref("browser.link.open_newwindow", 1);

In Camino 1.0 both links reuse the current tab, but in Camino 1.0+ (03.26) both links open a new window.

Comment 25

[froodian (Ian Leue)]

We ought to include javascript cases of window.open() as well, as exemplified by the testcases in Bug 103843.  There's some disagreement about whether all window.open() links should follow the SWM prefs, or if cases where the new window is resized should be let through, so we should figure out which we want to do before fixing this.

https://bugzilla.mozilla.org/attachment.cgi?id=160966 is the general-purpose case, and 
https://bugzilla.mozilla.org/attachment.cgi?id=160968 resizes the window.

Comment 26

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

(In reply to comment #25)
> There's some disagreement about whether all
> window.open() links should follow the SWM prefs, or if cases where the new
> window is resized should be let through, so we should figure out which we want
> to do before fixing this.

No, that's an implementation detail; we get everything working, and then we set the default prefs how we want them.

IMO browser.link.open_newwindow.restriction should be set to 2 (divert only if no size/foo called) by default when SWM is set to reuse or new tab and people who object wildly (like me) can set it to 0 (divert all window.open) manually vai about:config or user.js.

But none of this matters until bz's changes get hooked up and browser.link.open_newwindow and browser.link.open_newwindow.restriction actually work in Camino.  That's the issue here, we all know it's broken; what we need is someone to jump in and volunteer to hook bz's changes up in Camino.

Comment 27

[Mike Pinkerton (not reading bugmail)]

Attachment: patch against 18branch

patch against 1.8, applies cleanly to the trunk but i haven't yet built it. boy this was easy with the new apis ;)

Comment 28

[Mike Pinkerton (not reading bugmail)]

landed on trunk and 18branch. i'm guessing at the right branch keyword (fixed1.8.1?)

Comment 29

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

You rock, pink!

Take any complaints about what options are exposed via the UI to bug 184994.

Comment 30

[froodian (Ian Leue)]

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

Comment 31

[[e-mail]]

Verified fixed on 1.8 branch and trunk