Closed Bug 274143 (caminoSWM) Opened 18 years ago Closed 17 years ago
Fix "single-window mode" prefs
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
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.
18 years ago
not an 0.9 blocker
Target Milestone: Camino0.9 → Camino1.0
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....
*** 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. ***
17 years ago
Target Milestone: Camino1.1 → Camino2.0
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
*** 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
*** 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
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.
(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?)
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
You need to log in before you can comment on or make changes to this bug.