Closed Bug 13208 Opened 21 years ago Closed 20 years ago

Popups confuse navigator.xul persistence

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

VERIFIED DUPLICATE of bug 15555

People

(Reporter: waterson, Assigned: law)

References

Details

(Whiteboard: [HELP WANTED])

Ugh. This is something that we'll probably all need to get together to figure out. Any of the dreaded popups (e.g., at netscape's home page or at geocities) is "remembered" as your preferred browser size.

To reproduce:

1. Find a website that reliably brings up pop-up ads; e.g., http://home.netscape.com/ or http://www.geocities.com/.

2. Close the popup.

3. Open a new window. Note that its size will be the same as the popup's size.

Expected behavior: new window is same size as last browser window you opened via "new browser window".
OS: other → All
Hardware: PC → All
This isn't bad.  In the WinFE of 4.x, we just remembered whether or not a window
was opened using window.open, and made sure not to write out flags.  We could
annotate the content model (e.g., the window tag) with this info, and then the
unload check would know to look for that and not persist the attributes.

We do need to make sure that only the window.open that does NOT open chrome does
this, e.g., the normal browser window.open.
Actually we may be using window.open too much to do this.  Another idea is to
rely on the opener property.  If the opener is chrome, we persist, and if the
opener is content, we don't.  This annotation would be made up front at the time
you opened the window.
Status: NEW → ASSIGNED
Target Milestone: M11
I tried the window.opener check but ran into problems (window.opener was null;
that seems to have cleared up but perhaps only to our disabling of some security
stuff).

I think it might be sufficient to set a property on the browser window itself.
Our chrome can do that after it opens a browser window.  This seems to work
except that I ran into problems when I tested it with the File->Open Web
Location option (i.e., browser windows opened via that route).  See bug #13525.

I may go ahead and do this anyway, depending on what other obstacles I run into.
 It requires changing the code that opens windows to use window.open(Dialog).
Whiteboard: [HELP WANTED]
*** Bug 15014 has been marked as a duplicate of this bug. ***
Summary: popups confuse navigator.xul persistence → [DOGFOOD]popups confuse navigator.xul persistence
Whiteboard: [HELP WANTED] → [HELP WANTED] [PDT-]
Voted PDT-
Whiteboard: [HELP WANTED] [PDT-] → [PDT-][HELP WANTED]
Target Milestone: M11 → M12
Not high enough priority for my M11 attention.  Moving to M12.
Target Milestone: M12 → M13
This is currently blocked by general persist= flakiness.  The net result
of that is that the size of those tiny ad popups isn't remembered anyway.
Moving to M13.
Component: Browser-General → XUL
QA Contact: leger → paulmac
Updating QA contact.
*** Bug 21460 has been marked as a duplicate of this bug. ***
Summary: [DOGFOOD]popups confuse navigator.xul persistence → Popups confuse navigator.xul persistence
Whiteboard: [PDT-][HELP WANTED] → [HELP WANTED]
Target Milestone: M13 → M15
Not required for beta 1.
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL.  XUL 
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
*** Bug 24062 has been marked as a duplicate of this bug. ***
*** Bug 24062 has been marked as a duplicate of this bug. ***
Based on discussion in bug 24062, it seems that it will be impossible to
test this properly on Linux so long as  bug 17799, "[PP] Window size not 
remembered on Linux", NEW, M14, is not fixed. Currently the window size is 
not being remembered at all on Linux (at least on M14 builds), so testing to 
see if it being remembered when it shouldn't is not possible. 
Setting dependency.
Depends on: 24062
Now how did I get that wrong? the dependency is on bug 17799, fixing. 
Sorry 'bout the spam... break time.
Depends on: 17799
No longer depends on: 24062
I'm going to have to start checking law's bug list from now on -- funny how we 
often seem to end up working on the same bugs. Anyway, this bug is a dupe of 
15555. This one's older, but that one's fixed.


*** This bug has been marked as a duplicate of 15555 ***
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
cleaning up: VERIFY duplicate
Status: RESOLVED → VERIFIED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: paulmac → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.