Closed
Bug 597576
Opened 15 years ago
Closed 15 years ago
window.open appears to open popup with wrong size/position and then move/resize
Categories
(Core :: Widget: Win32, defect)
Tracking
()
VERIFIED
WORKSFORME
| Tracking | Status | |
|---|---|---|
| blocking2.0 | --- | final+ |
People
(Reporter: duncan.loveday, Assigned: jimm)
References
Details
(Keywords: regression, testcase)
Attachments
(1 file, 1 obsolete file)
|
422 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100917 Firefox/4.0b6pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b6pre) Gecko/20100917 Firefox/4.0b6pre
In the Firefox 4 beta a call like
window.open('test.html', 'test', 'top=100px,left=100px,height=200px,width=300px');
opens the popup with a size and position that differs from the given values and then immediately resizes and moves the window to the specified position. The effect is most noticeable when the parent window is maximised at the time the window.open() call is made.
Firefox 3.x just opens the popup in the right place.
Is that a bug ?
Reproducible: Always
Steps to Reproduce:
1. Load the test case
2. Maximise the firefox window.
3. Click the button and observe the behaviour of the popup.
Actual Results:
Popup appears at one position and size and is then moved and resized.
Expected Results:
Popup should appear with the correct position and size right away.
| Reporter | ||
Comment 1•15 years ago
|
||
| Reporter | ||
Updated•15 years ago
|
Keywords: regression,
testcase
Summary: window.open with appears to open popup with wrong size/position and then move/resize → window.open appears to open popup with wrong size/position and then move/resize
Comment 3•15 years ago
|
||
Maybe duplication of Bug 594881 or Bug 595811
Updated•15 years ago
|
Component: DOM: Core & HTML → Widget: Win32
QA Contact: general → win32
| Assignee | ||
Comment 5•15 years ago
|
||
(In reply to comment #3)
> Maybe duplication of Bug 594881 or Bug 595811
Bug 594881 has to do with restoring a size mode, so that really doesn't fit this. I think this has to do with sporadic size events sent to the window from the view prior to chrome being loaded.
blocking2.0: ? → final+
Comment 6•15 years ago
|
||
There is another similar bug, I mentioned this in bug 582755 comment 4
Comment 7•15 years ago
|
||
confirming, as there's a testcase and it's already been marked blocking.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•15 years ago
|
Assignee: nobody → jmathies
| Assignee | ||
Comment 9•15 years ago
|
||
Attachment #476417 -
Attachment is obsolete: true
| Assignee | ||
Updated•15 years ago
|
| Assignee | ||
Comment 10•15 years ago
|
||
A new fix landed in bug 574690 that should address this.
| Assignee | ||
Comment 11•15 years ago
|
||
on aero basic, win7
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
| Reporter | ||
Comment 12•15 years ago
|
||
Looking good for me on windows XP using the current nightly
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•