Bug 274143 (caminoSWM)

Fix "single-window mode" prefs

VERIFIED FIXED in Camino1.5

Status

defect
--
major
VERIFIED FIXED
15 years ago
5 years ago

People

(Reporter: alqahira, Assigned: mikepinkerton)

Tracking

({fixed1.8.1, regression, testcase})

Dependency tree / graph
Bug Flags:
camino1.5 +

Details

Attachments

(2 attachments)

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).
something to investigate for sure to make sure nothing regressed.
Target Milestone: --- → Camino0.9

Comment 2

15 years ago
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.
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.
Blocks: 172718

Comment 4

14 years ago
not an 0.9 blocker
Target Milestone: Camino0.9 → Camino1.0

Comment 5

14 years ago
Single window mode should be enabled in future releases. Thank you.
*** Bug 287824 has been marked as a duplicate of this bug. ***
(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.
(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

14 years ago
*** Bug 300310 has been marked as a duplicate of this bug. ***
*** Bug 299964 has been marked as a duplicate of this bug. ***
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?
Summary: Hook-up new /replacement "Single-window mode" prefs created after merge of aviary branch with trunk → Hook-up new/replacement "Single-window mode" prefs created after merge of aviary branch with trunk
Simon, Mike, as Smokey asked in comment 11, what has to happen to make this work?
a lot, we cannot do this for 1.0
Target Milestone: Camino1.0 → Camino1.1
*** Bug 319237 has been marked as a duplicate of this bug. ***
*** Bug 322468 has been marked as a duplicate of this bug. ***
*** Bug 322467 has been marked as a duplicate of this bug. ***
Target Milestone: Camino1.1 → Camino2.0

Comment 17

13 years ago
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?
(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.
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.
Target Milestone: Camino2.0 → Camino1.1

Comment 20

13 years ago
*** Bug 327726 has been marked as a duplicate of this bug. ***
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
Severity: enhancement → major
Summary: Hook-up new/replacement "Single-window mode" prefs created after merge of aviary branch with trunk → Fix "single-window mode" prefs
*** Bug 329591 has been marked as a duplicate of this bug. ***
This should block 1.1, because without a fix, we're *really* broken.

cl
Alias: caminoSWM
Flags: camino1.1?
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.

Updated

13 years ago
Keywords: testcase
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.
(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.
patch against 1.8, applies cleanly to the trunk but i haven't yet built it. boy this was easy with the new apis ;)
landed on trunk and 18branch. i'm guessing at the right branch keyword (fixed1.8.1?)
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Keywords: helpwantedfixed1.8.1
Resolution: --- → FIXED
You rock, pink!

Take any complaints about what options are exposed via the UI to bug 184994.
Flags: camino1.1? → camino1.1+
*** Bug 339547 has been marked as a duplicate of this bug. ***
Verified fixed on 1.8 branch and trunk
Status: RESOLVED → VERIFIED
Duplicate of this bug: 370116

Updated

12 years ago
Duplicate of this bug: 376715
You need to log in before you can comment on or make changes to this bug.