Closed Bug 482928 Opened 15 years ago Closed 15 years ago

All context menus/panels/popups appear on primary display/screen/monitor when Firefox is on secondary

Categories

(Core :: XUL, defect, P2)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.2a1

People

(Reporter: angelodiego, Assigned: masayuki)

References

Details

(Keywords: regression, verified1.9.1)

Attachments

(4 files, 2 obsolete files)

Screenshot of the issue. The red line shows the division between the left and right displays.
50.41 KB, image/png
Details
proposal patch v3.0
4.40 KB, patch
smichaud
: review+
roc
: review+
jimm
: review+
vlad
: superreview+
Details | Diff | Splinter Review
Patch v3.0 for 1.9.1 branch
6.21 KB, patch
roc
: review+
roc
: superreview+
Details | Diff | Splinter Review
Screenshot
504.07 KB, image/png
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090311 Minefield/3.2a1pre (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090311 Minefield/3.2a1pre (.NET CLR 3.5.30729)

With two monitors numbered 1 and 2, monitor one on the left , monitor 2 on the right.
Main monitor is 2 (check box in desktop properties), task bar is on monitor 1 and minefields opens on monitor 1
When clicking on a menu it pops up on the left margin of the second monitor instead of the correct position

Reproducible: Always
Confirming. This appeared in the nightlies on 20090311xxxx, haven't narrowed it down further than that yet.

Additionally, this occurs regardless of where display 2 is positioned. Top, bottom, left, right, the menu always appears on the side of the primary closest to Fx, not on the secondary like it should.
Status: UNCONFIRMED → NEW
Ever confirmed: true
clarifying title.
Summary: popup and menues popping in the wrong place → All menus, context menus, panels, etc, appear on primary display when Firefox is on secondary
Correction, this appeared after the 2009030903xx builds on Win32.
Assuming I followed Gavin's instructions correctly (it looks like I did, if not, blame me, not him) then this should be the changeset in which the offender is located.
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=50169589cc51&tochange=73efb0ef0d79
Grey, do you have the build ids too so the reporter can confirm your detected regressionrange?

So the browser window is not located on both screens right?
from their profile.ini files:

BuildID=20090309032542
SourceStamp=50169589cc51

BuildID=20090310044308
SourceStamp=73efb0ef0d79

It seems that menus sometimes appear correctly for a bit in the beginning. The way I have found to cause to occur is to close all tabs so that you are left with a new blank tab. I middle-click on the final tab and bam, issue is there.

You are correct, the browser is 100% contained on the secondary screen. I have Fx on my big desktop display, and use my laptop display for mail, IRC, etc. so Fx is routinely maximized on the right hand secondary big display.
Sorry but both still have the bug
That's interesting and a reason why I haven't any patch which could have been caused this problem. Would you have time to check for a regression range? Does it also appear with Firefox 3.1 nightly builds? Adding regression flags for now.

One bug which comes into my mind is bug 466169.
Keywords: regression, regressionwindow-wanted
Summary: All menus, context menus, panels, etc, appear on primary display when Firefox is on secondary → All menus, context menus, panels, etc, appear on primary display/screen/monitor when Firefox is on secondary
Bug 483520 also reports that on 64bit Windows7. Veritas can you please check comment 8 too? If that's not the regression range would you have time to narrow it down? That would be great.
Flags: blocking-firefox3.2?
Hardware: x86 → All
Version: unspecified → Trunk
i should have some time tomorrow to narrow it down.  There may also be something going on with multiple monitors in win7x64, because there is something really weird going on with the icons with both monitors up.  That said, thunderbird and other apps handle normally.  I am going to install the first build from comment8 to pinpoint the regression, ill report back.
well, so installing back to the first build "fixed" the problem?  It isn't appearing now, anyway.  Updating to the 2nd build listed had no change, and now using the update function to today's build Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090315 Minefield/3.2a1pre (.NET CLR 3.5.30729) seems to at least be working on the drop down menus.  I should note that opening additional windows (like the about window) incorrectly loads on the primary rather than the current monitor position, although I am unsure if this behavior is changed across the above two builds and todays.  I will check that tomorrow.  and before i even finished this paragraph, the error is back with the windows.  am going to revert to the first build again to see if i can't make it come back.
okay, so comment7 is right on the money.  to clarify the exact way to make this appear on any build starting with the 2nd posted on comment8, do the following.

1. open minefield (with one homepage tab, standard).
2. click plus sign to make new tab.
3. click close box on homepage tab, leaving the single blank tab.

this will trigger it every time.  and to confirm, the regression is indeed between builds 03-09-09 and 03-10-09.  hope this is helpful, if you want my help testing patch code or anything else, don't hesitate to ask.
I'm getting this on OSX also. Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090315 Minefield/3.2a1pre ID:20090315030726
It's with all context menus, the awesome bar search results, Google results, and the mouse then using the middle button scroll. Most effect when you add a monitor then remove it etc.
Bug exists. I did #15 posts technique and it began manifesting itself. Using:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090316 Minefield/3.2a1pre ID:20090316044350

While browsing the web in a normal way I can trigger this also, just didn't take note on what specific thing I did for it to start happening.
(In reply to comment #15)
> okay, so comment7 is right on the money.  to clarify the exact way to make this
> appear on any build starting with the 2nd posted on comment8, do the following.
> 
> 1. open minefield (with one homepage tab, standard).
> 2. click plus sign to make new tab.
> 3. click close box on homepage tab, leaving the single blank tab.

It looks like closing either the new tab or the old tab will trigger this.

There are also no errors on the Error Console when this happens.
This is a regression from bug 479749.
Blocks: 479749
Keywords: regressionwindow-wanted
OS: Windows XP → All
Component: Menus → XP Toolkit/Widgets: Menus
Flags: blocking-firefox3.6?
Product: Firefox → Core
QA Contact: menus → xptoolkit.menus
Flags: blocking1.9.2?
Looks like this has reached 1.9.1 too. I can see it for the auto-complete pop-up with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090322 Shiretoko/3.5b4pre ID:20090322030800

Really a regression from bug 479749? That one hasn't been checked into the branch yet.
Flags: blocking1.9.1?
I do not see this bug in 1.9.1 for any popup.
I'm not able to see it again right now. Until I don't have reliable steps we should remove the flag. Probably it will be another bug. I'll keep an eye on it.
Flags: blocking1.9.1?
(In reply to comment #23)
> I'm not able to see it again right now. Until I don't have reliable steps we
> should remove the flag. Probably it will be another bug. I'll keep an eye on
> it.

I just bumped across this issue today, using a nightly build [1], but wasn't (yet) able to find a reliable procedure to reproduce...

This occurred in Windows XP SP3, with a left-right dual monitor setup and the issue was affecting system menus (such as "File", "Edit", etc.).

[1] Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090330 Minefield/3.6a1pre
I also have this bug since ~2009030903xx on WinXP.  Everything is fine on the secondary screen on start up.  As soon as I close a tab, menus appear on the primary screen as shown in the screenshot.
(In reply to comment #26)

> As soon as I close a tab, menus appear on the primary screen as
> shown in the screenshot.

This very interesting, and provides a clue about the underlying bug(s)
that cause this problem (the patch for bug 479749 just uncovered
it/them).

I imagine closing a window is also enough to start the problem
happening.  Is this true?

And can others confirm that this problem doesn't start happening until
you've closed at least one tab (or window)?

(I don't have multiple monitors, so I can't run these tests myself.)
(In reply to comment #27)
> I imagine closing a window is also enough to start the problem
> happening.  Is this true?

No.


> And can others confirm that this problem doesn't start happening until
> you've closed at least one tab (or window)?

Yes, I confirm this information (thanks for the hint, void420@gmail.com).


Steps to reproduce:
1. Open a Minefield nightly build;
2. Move the window to the secondary monitor;
3. Create a new tab (can be blank);
4. Close any of the tabs;
5. Open a system menu ("File", "Edit", etc.).

Expected results:
In step 4, system menus are displayed in the secondary monitor.

Actual results:
In step 4, system menus are displayed in the primary monitor.

Additional information:
If the dual monitor setup is left-right, with secondary monitor right, step 4 displays system menus right-aligned (on the primary monitor); if secondary monitor is on the left, step 4 displays system menus left-aligned (on the primary monitor).

I've also checked that several variations (fortunately) don't affect reproducing the symptom:
 * Monitor in which Minefield is initially displayed when loaded;
 * Monitor in which the tab open/close operations occur;
 * Whether Minefield is configured to open with a blank tab, home page or set of previously opened tabs.

Version details:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090330 Minefield/3.6a1pre
I've already debugged this a bit and had mentioned it in bug 479749, but I'll mention it here as well (the other bug isn't visible to all).

The issue is caused because of the lines in nsBaseWidget::Destroy which clear the widget:

+  // Clear the device context's mWidget field -- otherwise it may get accessed
+  // after it's been deleted.  See bug 479749.
+  if (mContext)
+    mContext->Init(nsnull);

Removing these lines fix this bug.

The issue is caused because one device context can be used for multiple widgets and clearing the widget causes it to not work when used via the other ones.

Either:

- the device context shouldn't be storing a widget pointer (it's only used to get the screen details as well as some printing related thing)
- the widget should only be being cleared when some widgets are destroyed (top-level perhaps?)
(In reply to comment #29)

> Either:
>
> - the device context shouldn't be storing a widget pointer (it's
> only used to get the screen details as well as some printing related
> thing)
> - the widget should only be being cleared when some widgets are
> destroyed (top-level perhaps?)

I agree that one of these is probably the way to fix this problem.
I'd prefer the first.

You also clearly agree that the patch for bug 479749 didn't *cause*
this bug's problem -- it only triggered it.

I'm currently busy with other stuff, and can't work on this bug for
perhaps another two weeks.  Please work on this if you'd like.
Otherwise I'll give it a crack myself in a couple of weeks.
(In further reply to comment #29)

> - the widget should only be being cleared when some widgets are
> destroyed (top-level perhaps?)

Actually, if we can't avoid storing a widget pointer in the device
context, we should always use a long-lived widget (one that's
guaranteed to live as long as the window, perhaps).
(In reply to comment #28)

>> I imagine closing a window is also enough to start the problem
>> happening.  Is this true?
>
> No.

Sorry for the nitpicking ... but this may be important.

Do the following steps trigger this bug (in step 5)?

1. Open a Minefield nightly build.
2. Move the window to the secondary monitor.
3. Open another window.  If it doesn't appear in the secondary
   monitor, move it there.
4. Close one of the windows.
5. Open a system menu ("File", "Edit", etc.).
(In reply to comment #32)
> Sorry for the nitpicking ... but this may be important.

Sure, feel free to ask for more test cases. ;-)


> Do the following steps trigger this bug (in step 5)?

No. I should have included in my previous comment (#28) that I've also made several variations to make sure that window handling doesn't (to the extend of my tests, of course) reproduce the issue.
Opening / closing new windows does not trigger this bug for me either.  It only happens after I close a tab.  It does not matter on which screen I do it.

After I've closed a tab, the menus and popup are still fine if the browser is on the primary display but if I move it to the secondary the problem occurs.
Heh, I just noticed this even affects the Control-Tab panel, which appears beautifully translucent on my OTHER monitor. :)
i can also confirm that it does not require closing a tab to experience this behavior
Attached patch proposal patch v1.0 (obsolete) — — Splinter Review 
This patch fixes this bug and this should be safe. We should not clear the context if that doesn't own the destroying native widget.
Attachment #371095 - Flags: review?(smichaud)
Masayuki, does your patch regress the "second crash" of bug 479749?
(In reply to comment #39)
> Masayuki, does your patch regress the "second crash" of bug 479749?

I cannot reproduce the crash by the testing of bug 479749 comment 8.
I posted the patch to tryserver.
Tryserver build has resolved bug 482928 on x86_64, thank you Masayuki.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090405 Minefield/3.2a1pre Firefox/3.0.7 (.NET CLR 3.5.30729)
Thank you robg for your testing.

https://build.mozilla.org/tryserver-builds/2009-04-04_23:35-masayuki@d-toybox.com-attachment371095 [review]/

Steven: you can confirm the patch by the tryserver build.
It now works
Attachment #371095 - Flags: review?(smichaud) → review-
Comment on attachment 371095 [details] [diff] [review]
proposal patch v1.0

Masayuki, your patch does regress bug 479749's "second crash" -- see
bug 479749 comment #11.

I still think the best way to fix this problem is to stop the device
context storing a widget pointer.  But this may not be easy, and if
the fix is too complex it may not be landable on the 1.9.1 branch.

Second best is to always store a pointer to a long-lived widget (one
that lives as long as the browser window).  It's conceivable that
doing this may only require changes on the Mac (right now the Mac
stores a pointer to an NSView, which is very short-lived).  But I
don't know the relevant code very well -- particularly on other
platforms than the Mac.

I'm still working on the JEP -- which means that it'll be at least a
week before I can really start working on this bug.

Side note:  As best I can tell, the only place in the Mozilla tree
where an nsIDeviceContext is initialized to something else than 'NULL'
is in DocumentViewerImpl::CreateDeviceContext().  Is this correct?
> Side note:  As best I can tell, the only place in the Mozilla tree
> where an nsIDeviceContext is initialized to something else than 'NULL'
> is in DocumentViewerImpl::CreateDeviceContext().  Is this correct?

Aside from a couple of calls from OS/2 widget code.
> Second best is to always store a pointer to a long-lived widget (one
> that lives as long as the browser window).  It's conceivable that
> doing this may only require changes on the Mac (right now the Mac
> stores a pointer to an NSView, which is very short-lived).

It's conceivable that this might only require changes on the Mac *beyond Masayuki's patch*.
Wait. Why does the popup manager refer the device context which has the destroyed native widget on Mac? It seems that the device context should not be referred after the native widget is destroyed. Or, it seems that the device context has wrong native widget only on Mac.
> Why does the popup manager refer the device context which has the
> destroyed native widget on Mac?

Good question :-)  I don't (yet) know the answer.

> It seems that the device context should not be referred after the
> native widget is destroyed.

I agree -- it shouldn't.

> Or, it seems that the device context has wrong native widget only on
> Mac.

Possibly it's the wrong *kind* of widget.  Maybe it should be an
NSWindow object and not an NSView object (but this is just a guess).

Changing it to an NSWindow object would (probably) also require
changes elsewhere in Cocoa widgets code.
Attached patch proposal patch v2.0 (obsolete) — — Splinter Review 
ok, this should be safe.

But this patch changes the meaning of the nsDeviceContextImpl::mWidget, and the param of nsIScreenManager::screenForNativeWidget. Therefore, I need to change the UUID of nsIScreenManager...

This patch looks safe for other platforms, probably. Win32/GTK/QT uses same pointer to both NS_NATIVE_WINDOW and NS_NATIVE_WIDGET. And also OS/2 and BeOS don't refer the param of nsIScreenManager::screenForNativeWidget.
Attachment #371095 - Attachment is obsolete: true
Attachment #371379 - Flags: review?(smichaud)
Comment on attachment 371379 [details] [diff] [review]
proposal patch v2.0

This still regresses the "second crash" from bug 479749.  Though now
it doesn't crash 100% of the time -- you may need to close all
windows, quit Minefield, and rerun the test.

I may have been wrong about using a longer-lived widget.

Why not try combining your two patches?
Attachment #371379 - Flags: review?(smichaud) → review-
> Why not try combining your two patches?

On second though this isn't likely to work.

We may need to tackle this problem from another direction:  Find out
why nsScreenManagerCocoa::ScreenForNativeWidget() is being called "on"
a window that's been destroyed, and stop this from happening.
> Find out why nsScreenManagerCocoa::ScreenForNativeWidget() is being
> called "on" a window that's been destroyed, and stop this from
> happening.

It's conceivable this only happens on the Mac.
(In reply to comment #52)
> (From update of attachment 371379 [details] [diff] [review])
> This still regresses the "second crash" from bug 479749.  Though now
> it doesn't crash 100% of the time -- you may need to close all
> windows, quit Minefield, and rerun the test.

mmmm... I still couldn't reproduce this crash on my environment....
 
(In reply to comment #53)
> > Why not try combining your two patches?
> 
> On second though this isn't likely to work.

I think so, too.
>> (From update of attachment 371379 [details] [diff] [review] [details])
>> This still regresses the "second crash" from bug 479749.  Though now
>> it doesn't crash 100% of the time -- you may need to close all
>> windows, quit Minefield, and rerun the test.
>
> mmmm... I still couldn't reproduce this crash on my environment....

I can reproduce the crash almost 100% of the time, with your tryserver build and my own test build.  I'm testing on a recent (and very fast) MacPro running OS X 10.5.6.
Flags: blocking1.9.1?
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Steven:

I succeeded to reproduce the "second crash", sorry, I misunderstand the steps to reproduce it.

I have suspicion to the test now. It seems that the last two lines of the test is in same stack. If so, isn't this the trigger of the second crash? The first line of them makes pending reflows. And the next line will run without flushing the reflows. The tested feature implementation doesn't assume such case, maybe.

The crash should be really Gecko's bug (and also the tested feature implementation?), however, the crash should not be happened without buggy chrome level code if my guess is correct. So, I think that the second crash is a hidden bug in daily use.

The actual crash reason could be out of my working area...
Looks like this patch doesn't have the second crash, but I want your confirmation.

I guess that the previous patch's NSWindow which is the cause of the second crash is popup window. So, the NSWindow is child of another NSWindow and that is destroyed during the test. This patch uses top level widget's NSWindow. I tested this patch several times, but I couldn't reproduce the second crash.
Attachment #371379 - Attachment is obsolete: true
Attachment #371652 - Flags: review?(smichaud)
roc or dbaron:

The reftests has testing the text-decoration stacking test in quirks mode. This patch makes UNEXPECTED-PASS error.

> REFTEST TEST-PASS | file:///e:/builds/moz2_slave/sendchange-win32-unittest/mozilla/layout/reftests/text-decoration/text-decoration-zorder-1-standards.html |
> REFTEST TEST-UNEXPECTED-PASS | file:///e:/builds/moz2_slave/sendchange-win32-unittest/mozilla/layout/reftests/text-decoration/text-decoration-zorder-1-quirks.html |
> REFTEST   IMAGE: data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAyAAAAPoCAYAAAAmy5qxAAAfg0lEQVR4nO3d227jOBZA0fr/n655GiCNVBxdqC2KWgvwS9u6ODDDs92Z6T9/AQAAIn/uvgEAAOA9BAgAAJARIAAAQEaAAAAAGQECAABkBAgAAJARIAAAQEaAAAAAGQECAABkBAgAAJARIAAAQEaAAAAAGQECAABkBAgAAJARIAAAQEaAAAAAGQECAABkBAgAAJARIAAAQEaAAAAAGQECAABkBAgAAJARIAAAQEaAAAAAGQECAABkBAgAAJCZMkD+/Pn5AW/3aX1YIwDA7KYbVwxW8DPxAQA83XQji8EKfiY+AICnm25sMVjBv4kPAGAFU40uBiv4mfgAAFYw1fhisIKfiQ8AYAVTjTAGK/g38QEArGKaMcZgBQAA6zPuAwAAGQECAABkBAhM7rf/+OAKf7Y48j2t+PMBgJVMuTWvNDCMHIIMVO8kQM6dZ4WfDwCsZMqteaWhYdQQZKB6py3xscJn4soAAQDmMt32vNrgcEWA8B4C5J7zAADXmW57Xm14ECActSc+nv7ZECAA8B5Tbc8rDg8j3stqPxO2ESDnz/HknwkArGqq7XnFAWJ0gPAen9bDamvlqgABAOYzzRa94re6f/8KEI75bT2stl4ECAC8xzRb9GoD1f+N/pt23kGA3HMOAOB6U2zRv/1d+5MHiZEBwntsWQd3rZUr1unZc632ewMAVjbFFi1Arjue59m6Dkaul7PXu/vfXqz0OwMAVjfFNn3VUDODkUMZ7zBjgOyJjyP3IUAA4D1u36a/DguzBcjowa48lufa8/kvAuRofOy5FwECAO9x+za9d9A5e50t577qm90z98w77P3MjVorZyPjzgAZ/bsCALjWrdv0lYP/p+uN+rZ37zWP3ivv8YQAOXLskeufuXcAYF5TBcjXf3bVt5qjB6w91zt6n7zD0c/ZiPVyVUSceQ9n7h0AmNdtW/WV36Zuue7ecwsQrjZzgNzxHs5cEwCY13QB8vW5JwTInsHqyD3yHgJk/zWv+B0BAFzr1gD59NxVEVIPeQKELc5+1u8+/uy5Rt43ADC3W7brswP/HQHy6ditxxy5R97h7oAQIABA5bEBcnTQuCJAtg5We++P97g7IAQIAFDJt+sRw74AYSWjPuP1Z3vkuUbeMwAwt2kD5OtrBQgr2xLbZx9n7mHk+9lzzJHrAADzS7fsOwarPfdwxbFHz897CBABAgBvIkAECDcq4mPLZ+ruNSZAAOA9si37imHmyDkFCDMRID8fc+QaAMD8pg+Qr8euHCCGqPcp4+NIAJRrbESAAADPsESA7DmvAGEWKwbI0XMIEAB4j2TbPjsgzB4gW48Z8TrWMeLzPOq8o9aYAAEAfvOIAPl6jrsGpE/Hbj3mzGtYy6igHnXuEevrzPEjYgkAeIbLt+1qqLrjG1oBwlFXxcfR829ZXz8df1W8jHgtADCfLEBGnuuqb2mPHLfnemdew1qeHCB7H0fvd8RrAYD5XLp1jx4Srg6QvUPPiAAxRL3PiIF99DUECABQuWzrHj1cjRp4jpxj1GB15HnWc3V8HLnOb6+9Mj5+Ov+e9wQAPMfwrXvkcHLFN69bXn/VYHXkedbzxADZ8roz7+PM+gUAnuV12/fZQevM9fY8x5pGD+6jrjUq5Efe65nXAQDzet32XQ1//7oezKpeF1uuDwCs6XXbvACB7wQIAFB53TYvQOA7AQIAVF63zQsQ+E6AAACV8dv8n7kfHweti6837LwwmAABACoCRIBQmmANzLAutlx/6DUAgGmM35onGKZmGrQECP8xwRqYYV1suf7QawAA0xi/NU8wTM00aAkQ/mOCNTDDuthy/aHXAACmMX5rnmCYOjJkXTVsCRD+Y4J1sHdt3HX9odcAAKbxmq15S3xc8T9+9T+q5T8miA0BAgDcydYM3M7/CxYAvIdtHgAAyAgQAAAgI0AAAICMAAEAADICBAAAyAgQAAAgI0AAAICMAAEAADICBAAAyAgQAAAgI0AAAICMAAEAADICBAAAyAgQAAAgI0AAAICMAAEAADICBAAAyAgQAAAgI0AAAICMAAEAADICBAAAyAgQAAAgI0AAAICMAAEAADICBAAAyAgQAAAgI0AAAICMAAEAADICBAAAyAgQAAAgI0AAAICMAAEAADICBAAAyAgQAAAgI0AAAICMAAEAADICBAAAyAgQAAAgI0AAAICMAAEAADICBAAAyAgQAAAgMz5A/nhc/uC57v7svPUBAExj/NY8YFj48+Fx+yAzw4Pnunh9WCM/PACAaYzfmi8crm4fYmZ58FwXrg9r5MMDAJjG+K35ogHr9gFmpgfPddH6sEZ+eQAA0xi/NV8wYN0+vMz24LkGrw1rZOMDAJjGVFvzPwcr4O/fvx/iAwDgQaYaXwxW8DPxAQCsYKoRxmAF/yY+AIBVTDPGGKwAAGB9xn0AACAjQAAAgIwAgcn99h8fXOHPFke+pxV/PgCwkim35pUGhpFDkIHqnQTIufOs8PMBgJVMuTWvNDSMGoIMVO+0JT5W+ExcGSAAwFym255XGxyuCBDeQ4Dccx4A4DrTbc+rDQ8ChKP2xMfTPxsCBADeY6rtecXhYcR7We1nwjYC5Pw5nvwzAYBVTbU9rzhAjA4Q3uPTelhtrVwVIADAfKbZolf8VvfvXwHCMb+th9XWiwABgPeYZotebaD6v9F/0847CJB7zgEAXG+KLfq3v2t/8iAxMkB4jy3r4K61csU6PXuu1X5vAMDKptiiBch1x/M8W9fByPVy9np3/9uLlX5nAMDqptimrxpqZjByKOMdZgyQPfFx5D4ECAC8x+3b9NdhYbYAGT3YlcfyXHs+/0WAHI2PPfciQADgPW7fpvcOOmevs+XcV32ze+aeeYe9n7lRa+VsZNwZIKN/VwAA17p1m75y8P90vVHf9u695tF75T2eECBHjj1y/TP3DgDMa6oA+frPrvpWc/SAted6R++Tdzj6ORuxXq6KiDPv4cy9AwDzum2rvvLb1C3X3XtuAcLVZg6QO97DmWsCAPOaLkC+PveEANkzWB25R95DgOy/5hW/IwCAa90aIJ+euypC6iFPgLDF2c/63cefPdfI+wYA5nbLdn124L8jQD4du/WYI/fIO9wdEAIEAKg8NkCODhpXBMjWwWrv/fEedweEAAEAKvl2PWLYFyCsZNRnvP5sjzzXyHsGAOY2bYB8fa0AYWVbYvvs48w9jHw/e445ch0AYH7pln3HYLXnHq449uj5eQ8BIkAA4E0EiADhRkV8bPlM3b3GBAgAvEe2ZV8xzBw5pwBhJgLk52OOXAMAmN/0AfL12JUDxBD1PmV8HAmAco2NCBAA4BmWCJA95xUgzGLFADl6DgECAO+RbNtnB4TZA2TrMSNexzpGfJ5HnXfUGhMgAMBvHhEgX89x14D06ditx5x5DWsZFdSjzj1ifZ05fkQsAQDPcPm2XQ1Vd3xDK0A46qr4OHr+Levrp+OvipcRrwUA5pMFyMhzXfUt7ZHj9lzvzGtYy5MDZO/j6P2OeC0AMJ9Lt+7RQ8LVAbJ36BkRIIao9xkxsI++hgABACqXbd2jh6tRA8+Rc4warI48z3qujo8j1/nttVfGx0/n3/OeAIDnGL51jxxOrvjmdcvrrxqsjjzPep4YIFted+Z9nFm/AMCzvG77PjtonbnenudY0+jBfdS1RoX8yHs98zoAYF6v276r4e9f14NZ1etiy/UBgDW9bpsXIPCdAAEAKq/b5gUIfCdAAIDK67Z5AQLfCRAAoPK6bV6AwHcCBACovG6bFyDwnQABACqv2+YFCHwnQACAyuu2eQEC3wkQAKDyqm3+05B11dBjoOIJBAgAUHnNNr8lPq4YfAxUPIEAAQAqtnngdgIEAN7DNg8AAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABARoAAAAAZAQIAAGQECAAAkBEgAABAZsoA+fPn5we83af1YY0AALObblwxWMHPxAcA8HTTjSwGK/iZ+AAAnm66scVgBf8mPgCAFUw1uhis4GfiAwBYwVTji8EKfiY+AIAVTDXCGKzg38QHALCKacYYgxUAAKzPuA8AAGQECAAAkBEgMLnf/uODK/zZ4sj3tOLPBwBWMuXWvNLAMHIIMlC9kwA5d54Vfj4AsJIpt+aVhoZRQ5CB6p22xMcKn4krAwQAmMt02/Nqg8MVAcJ7CJB7zgMAXGe67Xm14UGAcNSe+Hj6Z0OAAMB7TLU9rzg8jHgvq/1M2EaAnD/Hk38mALCqqbbnFQeI0QHCe3xaD6utlasCBACYzzRb9Irf6v79K0A45rf1sNp6ESAA8B7TbNGrDVT/N/pv2nkHAXLPOQCA602xRf/2d+1PHiRGBgjvsWUd3LVWrlinZ8+12u8NAFjZFFu0ALnueJ5n6zoYuV7OXu/uf3ux0u8MAFjdFNv0VUPNDEYOZbzDjAGyJz6O3IcAAYD3uH2b/joszBYgowe78liea8/nvwiQo/Gx514ECAC8x+3b9N5B5+x1tpz7qm92z9wz77D3MzdqrZyNjDsDZPTvCgDgWrdu01cO/p+uN+rb3r3XPHqvvMcTAuTIsUeuf+beAYB5TRUgX//ZVd9qjh6w9lzv6H3yDkc/ZyPWy1URceY9nLl3AGBet23VV36buuW6e88tQLjazAFyx3s4c00AYF7TBcjX554QIHsGqyP3yHsIkP3XvOJ3BABwrVsD5NNzV0VIPeQJELY4+1m/+/iz5xp53wDA3G7Zrs8O/HcEyKdjtx5z5B55h7sDQoAAAJXHBsjRQeOKANk6WO29P97j7oAQIABAJd+uRwz7AoSVjPqM15/tkecaec8AwNzGb9d/PC5/sJQtsX32ceYeRr6fPcccuQ4AML/xW/bdw/kbHjzX3Z+dtz4AgGmkW/Md3+zuuYcrjj16fhZ19yD+1gcAMI1sa74iGI6cU4Awk+LPr7Z8pu6O/FH3CwDMb/oA+XrsygFiiHqfMj6OBEC5xkYECADwDEsEyJ7zChBmsWKAHD2HAAGA90i27bMDwuwBsvWYEa9jHSM+z6POO2qNCRAA4DePCJCv57hrQPp07NZjzryGtYwK6lHnHrG+zhw/IpYAgGe4fNuuhqo7vqEVIBx1VXwcPf+W9fXT8VfFy4jXAgDzyQJk5Lmu+pb2yHF7rnfmNazlyQGy93H0fke8FgCYz6Vb9+gh4eoA2Tv0jAgQQ9T7jBjYR19DgAAAlcu27tHD1aiB58g5Rg1WR55nPVfHx5Hr/PbaK+Pjp/PveU8AwHMM37pHDidXfPO65fVXDVZHnmc9TwyQLa878z7OrF8A4Flet32fHbTOXG/Pc6xp9OA+6lqjQn7kvZ55HQAwr9dt39Xw96/rwazqdbHl+gDAml63zQsQ+E6AAACV123zAgS+EyAAQOV127wAge8ECABQed02L0DgOwECAFRet80LEPhOgAAAlddt8wIEvhMgAEDlddu8AIHvBAgAUHnVNv9pyLpq6DFQ8QQCBACovGab3xIfVww+BiqeQIAAABXbPHA7AQIA72GbBwAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgIwAAQAAMgIEAADICBAAACAjQAAAgMz/APfhpl7HzoZfAAAAAElFTkSuQmCC

Do you know why we are using different stacking between standards mode and quirks mode? I think that the stacking should not be different between both modes excepting the backward compatibility.

http://www.w3.org/TR/CSS21/zindex.html#painting-order
CSS2.1 says that underline and overline should be drawn below the text.
oops, I posted to wrong bug, please ignore the previous comment.
Attachment #371652 - Flags: review?(smichaud) → review+
Comment on attachment 371652 [details] [diff] [review]
proposal patch v3.0

This time I think you've got it.

I tested your patch several times, and had no crashes.

> I guess that the previous patch's NSWindow which is the cause of the
> second crash is popup window. So, the NSWindow is child of another
> NSWindow and that is destroyed during the test. This patch uses top
> level widget's NSWindow.

Makes sense.  So we were right to use an NSWindow object instead of an
NSView object, but we also need to make sure it's an NSWindow object
corresponding to a top-level window.

I'm about to land my patch for bug 479749 on the 1.9.1 branch.
Hopefully you'll be able to land your patch on top of it in a few days
(on both the trunk and the 1.9.1 branch).
So I suppose the fact that Masayuki's v3.0 patch works implies that a
device context can be shared between a browser window and its child
windows.

I hope it can't be shared between top-level browser windows ... or bug
479749's "second crash" will come back to bite us again.
Possible (though unlikely) source of trouble from v3.0 patch:

On Windows nsIDeviceContext::mWidget is an HWND, and is used in
nsThebesDeviceContext::CalcPrintingSize().  I hope child windows can't
be printed ... or we'll be in trouble.
Comment on attachment 371652 [details] [diff] [review]
proposal patch v3.0

Steven:

Thank you. I know the HDC problem on Windows. Vlad should be best person of the sr.

Vlad, this patch changes the nsIDeviceContext::mWidget is always the top level widget's native widget. It can make trouble for Win and OS/2 printing code. Do you know whether this code creates actual problem?
Attachment #371652 - Flags: superreview?(vladimir)
Please ask roc to review this as well. I'm not convinced that any of the above or the analysis done is correct.
Comment on attachment 371652 [details] [diff] [review]
proposal patch v3.0

Requesting additional review to roc by previous comment.
Attachment #371652 - Flags: review?(roc)
Please also enable the assertion backed out in changeset 6386025d72c3 when this patch goes in.  The removed code in nsBaseWidget::Destroy() was triggering that assertion.
> changeset 6386025d72c3
bug 419125
Comment on attachment 371652 [details] [diff] [review]
proposal patch v3.0

Boy.. I really don't know what's using NS_NATIVE_WINDOW; I'd say if all the unit tests pass then it should be ok.  r?'ing jim as well here in case he has some input.
Attachment #371652 - Flags: review?(jmathies)
NS_NATIVE_WIDGET & NS_NATIVE_WINDOW both return the same hwnd so I don't see an issue with that. I wonder about any printing issues though with using the parent for metrics info and I'm not sure under what circumstance GetPrintHDC() would return null.
(In reply to comment #71)

Can a child window ever be printed?

(As opposed to a top-level browser window.)
I posted the patch to tryserver two times. The tests passed on tryserver builds. But I'm not sure the printing code is tested on them.

The comment 72 issue is not clear, yet. We are not sure whether the HWND is need of the child window's on Win32 and OS/2...
(In reply to comment #72)
> (In reply to comment #71)
> 
> Can a child window ever be printed?
> 
> (As opposed to a top-level browser window.)

It looks like when the device context is used for printing, mPrintingSurface is going to be valid. CalcPrintSize is only called once, from within InitForPrinting, after the mPrintingSurface is created. So it would seem  GetPrintHDC() will succeed and the hwnd will not be used.
Attachment #371652 - Flags: review?(jmathies) → review+
(In reply to comment #74)

So it sounds like it doesn't matter whether or not a child window can
be printed -- nsDeviceContext::mWidget will never be used in any case
(printing a child window or printing a top-level window).
Forgive me if this is simply unsurprising noise to those who understand the problem, but I've been using Minefield and Shredder nightlies on windows XP, and this bug just started happening with Shredder for me for the first time today.
(In reply to comment #76)

That's because the patch for bug 479749 (part of which triggered this
bug) has been landed on the 1.9.1 branch (as I mentioned in comment
#62).  Shredder is built from the 1.9.1 branch.  So is Shiretoko (what
will become Firefox 3.5).

Hopefully this bug's patch will be landed soon -- on both the trunk
(aka mozilla-central, used by Minefield) and the 1.9.1 branch.
Attachment #371652 - Flags: superreview?(vladimir) → superreview+
I'm using the nightlies for Thunderbird/Shredder on Windows 2000, and this problem only showed up on today's build, it never did prior to now.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1b4pre) Gecko/20090409 Lightning/1.0pre Shredder/3.0b3pre
http://hg.mozilla.org/mozilla-central/rev/e7cd77360f94
Assignee: nobody → masayuki
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Whiteboard: [c-n: baking for 1.9.1]
Target Milestone: --- → mozilla1.9.2a1
(In reply to comment #77)
> (In reply to comment #76)
> 
> That's because the patch for bug 479749 (part of which triggered this
> bug) has been landed on the 1.9.1 branch (as I mentioned in comment
> #62).  Shredder is built from the 1.9.1 branch.  So is Shiretoko (what
> will become Firefox 3.5).
> 
> Hopefully this bug's patch will be landed soon -- on both the trunk
> (aka mozilla-central, used by Minefield) and the 1.9.1 branch.

I am still having this problem - from about 4/9 up to and including today's nightly. (Shiretoko, Winxp SP3, dual screens, showing on main screen)
This bug's fix has (so far) only been landed on the trunk (mozilla-central) -- not yet on the 1.9.1 branch.
Can we get this landed on 1.9.1 now? It's baked long enough without regression.
I'll go to bed soon. If somebody can land the patch and can check the tinderbox, please do it.
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090411 Minefield/3.6a1pre ID:20090411032350
Status: RESOLVED → VERIFIED
Keywords: checkin-needed
Whiteboard: [c-n: baking for 1.9.1]
Why is it ok to change the behavior of this interface on branch?  Is it a completely internal interface that no embeddors or binary extensions should be using?
Sigh, no, sorry, my enthusiasm got the best of me; the fix needs to be in Firefox 3.5, but we shouldn't break interfaces if we have an option not to.

Jim or bz: can you please back this out from 191?
If this is a regression bug (as most people think it is) why shouldn't the fix go into 1.9.1?  Just curious as I am not as well versed in the development process of Mozilla as you guys.
Shane: the fix will go into 191 (that's why this bug is marked as blocking191+) but not as is, since it breaks an interface on which add-ons may be relying. That's all I'm saying in comment 90 after it was pointed out in comment 89.

Also, we should have tests here :)
Mike: Thanks for clarifying that it breaks an interface, in that case, should the status be changed from FIXED?
No (it's fixed on m-c), but the keyword indicating that it's fixed on branch should be removed.
Keywords: fixed1.9.1
Sorry I'm new to this (mozilla development project), but how can it be fixed if it breaks an interface?
Changing it on the trunk is acceptable. Changing it on the branch at this stage in the release cycle is not. The bug status tracks its state on trunk, and it's FIXED there. We need a new branch patch that doesn't change the interface, and once that lands we'll mark it fixed1.9.1 again (that's how we track branch status).
This creates new interface for 191branch.
Attachment #372548 - Flags: superreview?(roc)
Attachment #372548 - Flags: review?(roc)
Attachment #372548 - Flags: superreview?(roc)
Attachment #372548 - Flags: superreview+
Attachment #372548 - Flags: review?(roc)
Attachment #372548 - Flags: review+
And let's try this again - can we get the branch patch landed for 1.9.1? :)
Flags: blocking1.9.2?
Keywords: checkin-needed
Summary: All menus, context menus, panels, etc, appear on primary display/screen/monitor when Firefox is on secondary → All context menus/panels/popups appear on primary display/screen/monitor when Firefox is on secondary
Verified fixed on 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090415 Shiretoko/3.5b4pre ID:20090415031735
Flags: in-litmus?
Keywords: fixed1.9.1 → verified1.9.1
Attached image Screenshot — 
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090601 Shiretoko/3.5pre

I was able to reproduce similar behaviour just now.  However, restarting Shiretoko seems to have self corrected the issue.

STR:
1. Open Shiretoko with a few different tabs (one being Litmus)
2. Create a new window and drag it to your secondary screen
3. Open a few tabs on that window (one being Litmus)
4. Start editing/adding test cases in the secondary screen

RESULT:
Autocomplete for the test case name appears on primary monitor when the cursor is on the secondary monitor.

This is no longer reproducible having restarted Shiretoko.  However, we should probably keep an eye out for it.
This could also be related to what I was seeing a while back and which is reported as bug 465623.
Did you change your monitor config between starting up and testing in new window?  That is, did you plug in the second monitor after startup?  Not sure if it matters, but it would be a good place to start; see if we cache some data that we shouldn't be.
So... I just noticed thanks to a new profile that the Ctrl-tab panel still appears on the primary monitor. I noted this in comment 35 here, and didn't think of it since then. While all other facets SEEM to be fixed in this bug, Ctrl-tab doesn't. Not sure if that should be split off into a new bug, or if someone wants to reopen this, or what, so just commenting here as per Jesse.
Right, forgot to mention that. Jesse noticed that bug, and I wasn't sure the relationship between them. I'm going to use my powers of induction to induce an electric curr-- no, wait, Deduction, and deduce that 445749 is handling that and everyone's aware. Thanks.
This bug has reappeared on my mac
Component: XP Toolkit/Widgets: Menus → XUL
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: