Using window.open to open a window at (0,0) does not work

RESOLVED FIXED

Status

()

Core
Widget: Gtk
RESOLVED FIXED
13 years ago
13 years ago

People

(Reporter: nandhp, Assigned: roc)

Tracking

({regression, testcase})

Trunk
x86
Linux
regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050522 Firefox/1.0+
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050522 Firefox/1.0+

When using window.open with options top=0,left=0, the window will open in a
random position on the screen. One coordinate must be >0.

Reproducible: Always

Steps to Reproduce:
1. Use provided test case to open windows at (0,0), (0,10) and (10,0).
2.
3.

Actual Results:  
See Details.

Expected Results:  
Firefox should have opened the window where it was asked to.
(Reporter)

Comment 1

13 years ago
Created attachment 186086 [details]
Testcase

Comment 2

13 years ago
WFM Firefox 1.04 Win2k; looks to be Linux-specific.

Comment 3

13 years ago
I can confirm this with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2)
Gecko/20050613. Can't find a dupe.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirmed again.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050613 Firefox/1.0+

Comment #3 demonstrates that the bug is cross-product.

Updated

13 years ago
Assignee: nobody → general
Component: General → DOM: Level 0
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk

Updated

13 years ago
Keywords: testcase

Comment 5

13 years ago
This is probably a GTK widget bug. Using treeOwnerAsWin->SetPositionAndSize()
instead of treeOwnerAsWin->SetPosition() in
nsWindowWatcher::SizeOpenedDocShellItem in file
embedding/components/windowwatcher/src/nsWindowWatcher.cpp seems to fix this.

Comment 6

13 years ago
this is gtk2-only and regressed between linux suite trunk 2005051801 and
2005052002, probably bug 292657.
Assignee: general → roc
Component: DOM: Level 0 → Widget: Gtk
Depends on: 292657
Keywords: regression
QA Contact: ian → gtk
Created attachment 186289 [details] [diff] [review]
fix?

I can't reproduce this in my build, but it could be my window manager or
something else. I think I see what the problem is. Can someone try this patch?

Comment 8

13 years ago
(In reply to comment #7)
> Can someone try this patch?

WFM with that patch.
Attachment #186289 - Flags: superreview?(blizzard)
Attachment #186289 - Flags: review?(blizzard)
Attachment #186289 - Flags: review?(blizzard) → review?(pavlov)
pav, if you're not going to do this review, could you move the request to
someone who will?

Comment 10

13 years ago
Comment on attachment 186289 [details] [diff] [review]
fix?

sure
Attachment #186289 - Flags: review?(pavlov) → review+
Attachment #186289 - Flags: superreview?(blizzard) → superreview+
I'm not going to try for branch at this point. I'll land it on the trunk.
I wend ahead and checked this in on the trunk...
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Since this checkin, I'm getting many warnings when using firefox (just moving a window and then cliking in it is enough; also on initial window show):

WARNING: BOGUS code reached!, file /opt/source/mozilla/trunk-ff/mozilla/widget/src/gtk2/nsWindow.cpp, line 591
Can you add some representative stacks leading to that warning?  That'll probably help narrow it down quickly.

Comment 15

13 years ago
Created attachment 209429 [details]
stack for bogus warning

stack from startup.  I get the warning 6x during startup and 6x (sometimes) when I move a window.  The stacks from the warnings are indistinguishable.

Updated

13 years ago
Blocks: 325073
You need to log in before you can comment on or make changes to this bug.