Closed
Bug 482928
Opened 16 years ago
Closed 16 years ago
All context menus/panels/popups appear on primary display/screen/monitor when Firefox is on secondary
Categories
(Core :: XUL, defect, P2)
Core
XUL
Tracking
()
VERIFIED
FIXED
mozilla1.9.2a1
People
(Reporter: angelodiego, Assigned: masayuki)
References
Details
(Keywords: regression, verified1.9.1)
Attachments
(4 files, 2 obsolete files)
50.41 KB,
image/png
|
Details | |
4.40 KB,
patch
|
smichaud
:
review+
roc
:
review+
jimm
:
review+
vlad
:
superreview+
|
Details | Diff | Splinter Review |
6.21 KB,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
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
Comment 1•16 years ago
|
||
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
Comment 2•16 years ago
|
||
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
Comment 3•16 years ago
|
||
Correction, this appeared after the 2009030903xx builds on Win32.
Comment 4•16 years ago
|
||
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
Comment 5•16 years ago
|
||
Comment 6•16 years ago
|
||
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?
Comment 7•16 years ago
|
||
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.
Comment 8•16 years ago
|
||
Angelo, could you please try the following builds? The first one should work while the second one will probably fail. Can you confirm that?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/03/2009-03-09-03-mozilla-central/firefox-3.2a1pre.en-US.win32.zip
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2009/03/2009-03-10-04-mozilla-central/firefox-3.2a1pre.en-US.win32.zip
Reporter | ||
Comment 9•16 years ago
|
||
Sorry but both still have the bug
Comment 10•16 years ago
|
||
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
Updated•16 years ago
|
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
Comment 12•16 years ago
|
||
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
Comment 13•16 years ago
|
||
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.
Comment 14•16 years ago
|
||
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.
Comment 15•16 years ago
|
||
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.
Comment 16•16 years ago
|
||
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.
Comment 17•16 years ago
|
||
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.
Comment 19•16 years ago
|
||
(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.
Updated•16 years ago
|
Keywords: regressionwindow-wanted
OS: Windows XP → All
Updated•16 years ago
|
Component: Menus → XP Toolkit/Widgets: Menus
Flags: blocking-firefox3.6?
Product: Firefox → Core
QA Contact: menus → xptoolkit.menus
Updated•16 years ago
|
Flags: blocking1.9.2?
Comment 21•16 years ago
|
||
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?
Comment 22•16 years ago
|
||
I do not see this bug in 1.9.1 for any popup.
Comment 23•16 years ago
|
||
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?
Comment 25•16 years ago
|
||
(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
Comment 26•16 years ago
|
||
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.
Comment 27•16 years ago
|
||
(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.)
Comment 28•16 years ago
|
||
(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
Comment 29•16 years ago
|
||
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?)
Comment 30•16 years ago
|
||
(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.
Comment 31•16 years ago
|
||
(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).
Comment 32•16 years ago
|
||
(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.).
Comment 33•16 years ago
|
||
(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.
Comment 34•16 years ago
|
||
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.
Comment 35•16 years ago
|
||
Heh, I just noticed this even affects the Control-Tab panel, which appears beautifully translucent on my OTHER monitor. :)
Comment 37•16 years ago
|
||
i can also confirm that it does not require closing a tab to experience this behavior
Assignee | ||
Comment 38•16 years ago
|
||
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)
Comment 39•16 years ago
|
||
Masayuki, does your patch regress the "second crash" of bug 479749?
Assignee | ||
Comment 40•16 years ago
|
||
(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.
Assignee | ||
Comment 41•16 years ago
|
||
I posted the patch to tryserver.
Comment 42•16 years ago
|
||
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)
Assignee | ||
Comment 43•16 years ago
|
||
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.
Reporter | ||
Comment 44•16 years ago
|
||
It now works
Updated•16 years ago
|
Attachment #371095 -
Flags: review?(smichaud) → review-
Comment 45•16 years ago
|
||
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?
Comment 46•16 years ago
|
||
> 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.
Comment 47•16 years ago
|
||
> 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*.
Assignee | ||
Comment 48•16 years ago
|
||
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.
Comment 49•16 years ago
|
||
> 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.
Assignee | ||
Comment 50•16 years ago
|
||
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)
Assignee | ||
Comment 51•16 years ago
|
||
Comment 52•16 years ago
|
||
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-
Comment 53•16 years ago
|
||
> 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.
Comment 54•16 years ago
|
||
> 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.
Assignee | ||
Comment 55•16 years ago
|
||
(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.
Comment 56•16 years ago
|
||
>> (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.
Updated•16 years ago
|
Flags: blocking1.9.1?
Updated•16 years ago
|
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P2
Assignee | ||
Comment 57•16 years ago
|
||
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...
Assignee | ||
Comment 58•16 years ago
|
||
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)
Assignee | ||
Comment 59•16 years ago
|
||
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.
Assignee | ||
Comment 60•16 years ago
|
||
oops, I posted to wrong bug, please ignore the previous comment.
Assignee | ||
Comment 61•16 years ago
|
||
test builds of patch v3:
https://build.mozilla.org/tryserver-builds/2009-04-08_04:17-masayuki@d-toybox.com-attachment371652 [review]/
Updated•16 years ago
|
Attachment #371652 -
Flags: review?(smichaud) → review+
Comment 62•16 years ago
|
||
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).
Comment 63•16 years ago
|
||
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.
Comment 64•16 years ago
|
||
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.
Assignee | ||
Comment 65•16 years ago
|
||
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)
Comment 66•16 years ago
|
||
Please ask roc to review this as well. I'm not convinced that any of the above or the analysis done is correct.
Assignee | ||
Comment 67•16 years ago
|
||
Comment on attachment 371652 [details] [diff] [review]
proposal patch v3.0
Requesting additional review to roc by previous comment.
Attachment #371652 -
Flags: review?(roc)
Comment 68•16 years ago
|
||
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.
Comment 69•16 years ago
|
||
> 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)
Comment 71•16 years ago
|
||
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.
Comment 72•16 years ago
|
||
(In reply to comment #71)
Can a child window ever be printed?
(As opposed to a top-level browser window.)
Attachment #371652 -
Flags: review?(roc) → review+
Assignee | ||
Comment 73•16 years ago
|
||
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...
Comment 74•16 years ago
|
||
(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.
Updated•16 years ago
|
Attachment #371652 -
Flags: review?(jmathies) → review+
Comment 75•16 years ago
|
||
(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).
Comment 76•16 years ago
|
||
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.
Comment 77•16 years ago
|
||
(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+
Comment 78•16 years ago
|
||
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
Assignee | ||
Comment 79•16 years ago
|
||
Assignee: nobody → masayuki
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Whiteboard: [c-n: baking for 1.9.1]
Target Milestone: --- → mozilla1.9.2a1
Comment 81•16 years ago
|
||
(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)
Comment 82•16 years ago
|
||
This bug's fix has (so far) only been landed on the trunk (mozilla-central) -- not yet on the 1.9.1 branch.
Comment 83•16 years ago
|
||
Can we get this landed on 1.9.1 now? It's baked long enough without regression.
Assignee | ||
Comment 84•16 years ago
|
||
I'll go to bed soon. If somebody can land the patch and can check the tinderbox, please do it.
Comment 87•16 years ago
|
||
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
Comment 88•16 years ago
|
||
Keywords: checkin-needed,
regression
Comment 89•16 years ago
|
||
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?
Updated•16 years ago
|
Keywords: fixed1.9.1,
regression
Comment 90•16 years ago
|
||
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?
Comment 91•16 years ago
|
||
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.
Comment 92•16 years ago
|
||
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 :)
Comment 93•16 years ago
|
||
Mike: Thanks for clarifying that it breaks an interface, in that case, should the status be changed from FIXED?
Comment 94•16 years ago
|
||
backed out of 1.9.1:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/291cbc374b67
Comment 95•16 years ago
|
||
No (it's fixed on m-c), but the keyword indicating that it's fixed on branch should be removed.
Keywords: fixed1.9.1
Comment 96•16 years ago
|
||
Sorry I'm new to this (mozilla development project), but how can it be fixed if it breaks an interface?
Comment 97•16 years ago
|
||
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).
Assignee | ||
Comment 98•16 years ago
|
||
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+
Comment 99•16 years ago
|
||
And let's try this again - can we get the branch patch landed for 1.9.1? :)
Updated•16 years ago
|
Flags: blocking1.9.2?
Keywords: checkin-needed
Assignee | ||
Comment 100•16 years ago
|
||
Keywords: checkin-needed → fixed1.9.1
Updated•16 years ago
|
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
Comment 103•16 years ago
|
||
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.
Comment 106•16 years ago
|
||
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.
Comment 107•16 years ago
|
||
Comment 108•16 years ago
|
||
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.
Comment 109•12 years ago
|
||
This bug has reappeared on my mac
Updated•6 years ago
|
Component: XP Toolkit/Widgets: Menus → XUL
You need to log in
before you can comment on or make changes to this bug.
Description
•