Closed
Bug 873032
Opened 11 years ago
Closed 11 years ago
Private browsing window shouldn't open directly over invoking regular browser window
Categories
(SeaMonkey :: UI Design, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: rsx11m.pub, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [fixed by bug 874042])
Observed behavior: When opening a private window, either by File > New > Private window or from a link's right-click context menu > Open Link in Private Window, it opens exactly at the same location as the invoking window. Expected behavior: Similar to the behavior seen File > New > Browser window or link right-click > Open Link in New Window, the private window should open with a slight offset to make it clear that it's a new window and not the same one. BTW: The same happens when opening a new regular window from a private window. Opening a new private window from a private window opens with an offset.
I'm unable to reproduce this on Linux, most likely because KDE takes care of the actual window placement and thus overrides any application-specific method.
|
||
Comment 2•11 years ago
|
||
So, what happens here is that we use the same chrome URL for private and non-private windows, but their windowtype is different (which stops people from accidentally loading things into non-private windows). However this means that private and non-private windows are arranged independently.
We could do what Firefox does and not change the windowtype but instead every time we look for a navigator window we would have to check that it's not private. In particular getMostRecentWindow("navigator:browser") would have to be rewritten to use an enumerator instead.
We could try setting the windowtype later but that would only solve the open private from nonprivate window case.(In reply to neil@parkwaycc.co.uk from comment #2) > We could do what Firefox does and not change the windowtype but instead > every time we look for a navigator window we would have to check that it's > not private. In particular getMostRecentWindow("navigator:browser") would > have to be rewritten to use an enumerator instead. Yes, Firefox uses a separate attribute to identify private browsing windows: (Quoting myself from bug 872521 comment #3) > Firefox sets in their browser.js implementation as part of the > gPrivateBrowsingUI.init() constructor a main-window attribute > "privatebrowsingmode" which is either "permanent" (SeaMonkey doesn't have > this mode properly implemented yet per bug 842618) or "temporary" for > per-window private browsing. In their themes, this is matched with > respective rules for #main-window[privatebrowsingmode=temporary].
Closing as fixed per observation in bug 874042 comment #3, the patch there solved this issue as well.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 874042]
You need to log in
before you can comment on or make changes to this bug.
Description
•