Closed Bug 545892 Opened 14 years ago Closed 14 years ago

Plugins kill aero glass / browser window sometimes loses aero glass effect

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows 7
defect
Not set
normal

Tracking

(blocking2.0 beta7+, blocking1.9.2 -, status1.9.2 .13-fixed, status1.9.1 unaffected)

RESOLVED FIXED
Tracking Status
blocking2.0 --- beta7+
blocking1.9.2 --- -
status1.9.2 --- .13-fixed
status1.9.1 --- unaffected

People

(Reporter: jimm, Assigned: jimm)

References

()

Details

(Keywords: regression)

Attachments

(10 files, 3 obsolete files)

1.85 KB, patch
ted
: review+
Details | Diff | Splinter Review
2.04 KB, patch
Callek
: review+
Details | Diff | Splinter Review
358.49 KB, text/plain
Details
1.37 KB, text/plain
Details
38.40 KB, image/png
Details
889 bytes, text/html
Details
203.14 KB, application/octet-stream
Details
1.16 KB, patch
bent.mozilla
: review+
Details | Diff | Splinter Review
1.57 KB, patch
bent.mozilla
: review+
Details | Diff | Splinter Review
225.47 KB, image/jpeg
Details
Probably has something to do with the subclassing going on. As soon as shockwave loads up, aero glass goes away. Flash does not exhibit the same behavior.
It appears that mozilla-runtime.exe doesn't have a manifest, and this is likely to cause problems. Odd that we wouldn't have noticed before, though!
Assignee: nobody → benjamin
Jim tried fixing this in bug 538990, but I guess our build system foiled him.
Blocks: 538990
Comment on attachment 426848 [details] [diff] [review]
Embed srcdir manifests if there aren't generated ones, rev. 1
[Checkin: See comment 9]

>diff --git a/config/rules.mk b/config/rules.mk
>--- a/config/rules.mk
>+++ b/config/rules.mk
>+			echo "Embedding manifest from and $@.manifest"; \

You have an extra 'and' in there.
Attachment #426848 - Flags: review?(ted.mielczarek) → review+
Hmm, my local debug/opt builds of mozilla-runtime.exe have the manifest embedded, and I still see the shockwave issue.
Well, ok: what kinds of things can turn glass off? We should commit this anyway, even if it doesn't solve this issue.

http://blogs.msdn.com/kamvedbrat/archive/2006/04/02/566788.aspx might be a clue.
What I've read so far indicates the dwm will shut down if the app tries to access the desktop directly through technologies like DirectDraw. Unfortunately setting shockwave up to use Direct-X 9 only didn't seem to help. (right-click, options). Still searching for something. API calls from the runtime when this kicks in seem pretty tame too. Not sure what's going on.
Not worth spending any time on, we have bigger fish to fry.
Comment on attachment 426848 [details] [diff] [review]
Embed srcdir manifests if there aren't generated ones, rev. 1
[Checkin: See comment 9]


http://hg.mozilla.org/mozilla-central/rev/e4a00f925137
Attachment #426848 - Attachment description: Embed srcdir manifests if there aren't generated ones, rev. 1 → Embed srcdir manifests if there aren't generated ones, rev. 1 [Checkin: See comment 9]
Comment on attachment 426848 [details] [diff] [review]
Embed srcdir manifests if there aren't generated ones, rev. 1
[Checkin: See comment 9]


Fwiw, I'm wondering about
*'$(srcdir)' in comments vs '$(win_srcdir)' in commands;
*'$(HOST_PROGRAM):' block just below which didn't have the same change.
(In reply to comment #10)
> (From update of attachment 426848 [details] [diff] [review])
> 
> Fwiw, I'm wondering about
> *'$(srcdir)' in comments vs '$(win_srcdir)' in commands;

mt.exe needs windows-style paths in its arguments, unix-style paths are fine everywhere else.

> *'$(HOST_PROGRAM):' block just below which didn't have the same change.

Don't care, we don't ship those binaries to anyone.
Comment on attachment 426848 [details] [diff] [review]
Embed srcdir manifests if there aren't generated ones, rev. 1
[Checkin: See comment 9]

> $(PROGRAM): $(PROGOBJS) $(LIBS_DEPS) $(EXTRA_DEPS) $(EXE_DEF_FILE) $(RESFILE) $(GLOBAL_DEPS)
>+	@rm -f $@.manifest

Ted won't this remove the src .manifest when not doing an objdir build, making things more difficult overall. Or is non-Objectdir build officially unsupported now?
Comment on attachment 427800 [details] [diff] [review]
(Bv1-CC) Copy it to comm-central (1.9.2+)
[Checkin: Comment 18]

even with my last comment here, r+ as we can live with bug-compat for now.
Attachment #427800 - Flags: review?(bugspam.Callek) → review+
We already have that problem. (I think it's already filed somewhere.) And yes, I care very little about srcdir builds.
Comment on attachment 427800 [details] [diff] [review]
(Bv1-CC) Copy it to comm-central (1.9.2+)
[Checkin: Comment 18]


http://hg.mozilla.org/comm-central/rev/5fe268312c4c
Attachment #427800 - Attachment description: (Bv1-CC) Copy it to comm-central → (Bv1-CC) Copy it to comm-central (1.9.2+) [Checkin: Comment 18]
Depends on: 426888
(In reply to comment #15)
> We already have that problem. (I think it's already filed somewhere.)

Bug 426888 ;-)
this bug is not only shockwave related.
i dont even have shockwave installed right now and got that issue as you can see here:
http://Jing.GottZ.de/2010-03-12_1358.png

happend now two times for me that it turned to non-aero.

3.7a3pre 32bit | win 7 ultimate 32bit
Jan, what plugins do you have installed? What websites were you viewing at the time it happened?
I am seeing this when I kill the flash plugin but it seems to affect all the existing (not new!) windows in the browser process, even if they are minimized. I don't know of a fix or even the cause.
blocking2.0: --- → ?
This bug appears to be related to bug 558479 somehow. Once when moving the misinformed window with winkey+arrows, I could trigger this bug reliably on just that window. This probably means that shockwave is not actually involved since the only tab open was about:blank. I have also not been able to reproduce with IPC disabled so that may be another clue (irritatingly enough, my browser kept crashing with ipc disabled!).
Attached file Spy++ message trace (obsolete) —
I was able to capture the bug under spy++. This trace does not include the child process. Mixed into this message trace is unfortunately the creation of a new window - the bug triggered right around the same time I tried to open a new window.

There are a number of undocumented messages. Spy++ also does not recognize all the new messages in Vista/7. Points of interest include the mysterious 0x03CC and 0x0322 messages, the latter of which falls into the DWM range. Also note the 0x31F messages with wParam:0 which indicate that glass has been disable for those windows.

This is probably not enough evidence to find the cause so I will keep trying.
Attached file Smaller simple trace —
I got a simpler trace. This is started during the hang. I then killed plugin-container and let it run. Since the window dimensions/layout are messed up, I played with the window a bit to get it to repaint properly.

There's nothing particularly unusual about this trace, I think the IME traffic is normal given that I clicked on the window and discovered the hang but I'd like to remove it if possible.

This particular stack of windows has the "Static" control bug that I mentioned to bsmedberg earlier today on IRC.
Attachment #442615 - Attachment is obsolete: true
Attached file Stack trace of offending call —
I did some debugging on this with the Shockwave testcase. The undocumented 0x0322 message appears to be responsible for making uxtheme.dll in the parent process disable nc rendering (it is the message being dispatched in the stack trace). If I fixup that call to use the window style instead of disabling, everything appears to work (I didn't do any exhaustive tests) and glass is never disabled for that window again, even after reload.

I would like to know what that message is, who is posting it and why they are posting it. bsmedberg pointed me to WH_JOURNALRECORD which may be useful for determining this.
Summary: Shockwave kills aero glass on the browser → [OOPP] Shockwave kills aero glass / browser window sometimes looses aero glass effect
Seems like something we should fix for 1.9.3
blocking2.0: ? → final+
Keywords: regression
Summary: [OOPP] Shockwave kills aero glass / browser window sometimes looses aero glass effect → [OOPP] Plugins kill aero glass / browser window sometimes looses aero glass effect
Assignee: benjamin → nobody
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6

This happens to me all the time...
blocking1.9.2: --- → ?
I can confirm this with the new Minefield beta 2 pre.  It only happens to me after I play a quake live game (and it happens every single time, so it's a good test case).
We'll take this in 1.9.2 if a safe fix becomes available, but we won't block a release on it.
blocking1.9.2: ? → -
Summary: [OOPP] Plugins kill aero glass / browser window sometimes looses aero glass effect → Plugins kill aero glass / browser window sometimes looses aero glass effect
Blocks: 579228
Blocks: 578165
We really need to track this down, it's been ignored for too long.
Assignee: nobody → jmathies
I really don't think this is a high priority right now.
FWIW this problem occurs for me fairly regularly.  I don't know if there is a specific site that triggers it, but nothing that is obviously "flash-heavy".  I have resorted to using Flash-Block to avoid the issue.

Mozilla/5.0 (Windows; U; Windows NT 6.1; WOW64; en-US; rv:2.0b1) Gecko/20100630 Firefox/4.0b1
This seems to track to 3.6.4, which makes it seem likely it's related to plugin process isolation.
(In reply to comment #42)
> This seems to track to 3.6.4, which makes it seem likely it's related to plugin
> process isolation.

OOPP plays a part in this sometimes, but robarnold also managed to find an obscure way to trigger this without plugins running.
Attached image Screenshot —
Would this bug be responsible for the tab bar corruption in the attached screenshot? Since installing 4.0 beta 2 (I am currently running beta 4) I experience frequent hangs. These resolve themselves after about 2 minutes after which the tab bar is completely illegible and I can't interact with the minimize/maximize/close controls.

If not I can file a new bug, just trying to avoid dupes.
I've been having the exact same issue as Jon Henry ever since I upgraded to beta 4 several days ago. I never had this problem with any of the other betas, though.
happened to me using fx 4 b4, happened when java crashed
I am seeing the same visual symptoms as Jon Henry using Firefox 4 beta 4.
(In reply to comment #48)
> I've been having the exact same issue as Jon Henry ever since I upgraded to
> beta 4 several days ago. I never had this problem with any of the other betas,
> though.

I think I've figured out what specific plugin is causing this issue; at least for me. The aero graphics issue seems to occur immediately after I open any pdf file within firefox using the adobe reader plugin.
Any plugin which can effect drawing in the title bar or uses hardware acceleration can cause the glass effect to die.
(In reply to comment #51)
> (In reply to comment #48)
> > I've been having the exact same issue as Jon Henry ever since I upgraded to
> > beta 4 several days ago. I never had this problem with any of the other betas,
> > though.
> 
> I think I've figured out what specific plugin is causing this issue; at least
> for me. The aero graphics issue seems to occur immediately after I open any pdf
> file within firefox using the adobe reader plugin.

Hmm what version? I've got Version: 9.3.4.218 and don't have an issue. A reliable site, plugin, or testcase would be most helpful in tracking this down.
(In reply to comment #52)
> Any plugin which can effect drawing in the title bar or uses hardware
> acceleration can cause the glass effect to die.

Plugins generally shouldn't effect drawing in the titlebar but they certainly do use accel. Flash is a good example. Do you know of a specific plugin that reproduces this reliably?
(In reply to comment #47)
> Created attachment 469488 [details]
> Screenshot
> 
> Would this bug be responsible for the tab bar corruption in the attached
> screenshot? Since installing 4.0 beta 2 (I am currently running beta 4) I
> experience frequent hangs. These resolve themselves after about 2 minutes after
> which the tab bar is completely illegible and I can't interact with the
> minimize/maximize/close controls.
> 
> If not I can file a new bug, just trying to avoid dupes.

Beta 5 should address this (hopefully) in some respects. We didn't have support for Aero Basic titlebar rendering in beta 4. We have it in beta 5, which should be out soon. You can also try a nightly:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
hit save too soon,

anyway, It occurs when changes occur in the browser, applet, or plugin but the
one of them is "Hung" doing other things, or the plugin mini-pauses during an
update and becomes out of sync with the browser.

It isn't specifically isolated to plugins which use acceleration either, any
plugin that accepts input from the browser can bring down aero if the browser
stops updating for more then 5 seconds.

I've done a bit of searching and found some sites that this issue can be
reproduced easily on, crunchroll, for one, if you scroll the page too soon
after entering the page, or enabling the flash applet(if flashblock is used).
Aero can die.

myfreecams was mentioned to me by a friend, and this seems to use flash quite
intensely just browsing the chat user list, typing into the filters list can
cause aero to die if you attempt to type during the "Hang" period where it is
updating the view.

If a flash applet changes the title bar it can bring it down as well.

And unsurprisingly Aero just died on me while typing this out, as the browser
"hung" while typing.  I do have 2 flash applets open so its definitely related.
Regarding 4.0b6pre/b5 i have not been able to get it to kill Aero there...

any chance of porting the improvements from trunk to 3.6.10?
(In reply to comment #57)
> Regarding 4.0b6pre/b5 i have not been able to get it to kill Aero there...
> 
> any chance of porting the improvements from trunk to 3.6.10?

We would have to track down whatever changes address the problem you were seeing. Usual way to do this is to install various nightlies to nail down a point in time where the problem goes away.
Freezes in the plugin process could definitely cause this, but there is clearly another cause, as the example url illustrates. (Shockwave will kill aero glass instantly and keep running.)
It doesn't appear to kill 3.6.9's glass, but definitely on 4.x
(In reply to comment #60)
> It doesn't appear to kill 3.6.9's glass, but definitely on 4.x

shockwave isn't out of process in 3.6.9.
ah, retested with ipc enabled.

I take it adobe says theres no issue on their side then?
oh and just an addendum on my hanging post, Aero also comes back for the brief instant Firefox pauses while opening multiple tabs, and if a plugin causes a small pause, then goes back to basic.
Blocks: 595835
No longer depends on: 426888
I'm on beta 5, and I'm getting the same thing with the tab bar. The background goes black in regular mode and invisible when maximized, and the min/max/close are missing. There doesn't seem to be any particular action that triggers it, although I think it happened once when I came back from sleep mode. Back in 3.6, it was just going into plain old Aero Basic.
Actually, another, probably more useful, note: After this happens, when I click the taskbar or another program, the titlebar briefly flashes the standard Aero Basic titlebar complete with full page title, and again when I click back into Firefox.
What I'm looking for here is reproducible cases on sites, plugins, or computer actions. Specific STR would be most helpful.
Blocks: 596036
Blocks: 586716
Just discovered that F11, fullscreen mode, looks like it fixes the glass issue -- unfortunately the seemed fix is transient and the window returns to broken mode. I will keep chasing this issue until I get STR.
First part of testcase
To reproduce:
1) Open 1st part of testcase (windowless youtube video) and play it
2) Open Translation Aggregator 0.4.3

After that Firefox window loses aero glass

If necessary, I can supply source code of Translation Aggregator 0.4.3 (it's not my program, I download files from http://www.hongfire.com/forum/showthread.php?t=94395 )
If you have lots of Youtube tabs open, the bug occurs. It's not always the Youtube window that loses the Aero theme. It can affect other FF windows too, and the window with Youtube tabs might remain unaffected.

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:2.0b7pre) Gecko/20100929 Firefox/4.0b7pre

Flash 10,2,161,22 (x64 preview)
The only time I ever see this issue is when I forcibly kill Java.
I wonder if we might be able to query ms folks about this. We understand what happens, windows sends us a WM_DWMNCRENDERINGCHANGED notification and then proceeds to shut down glass on our window. Unfortunately the cause of this is not well understood. We know plugins can sometimes trigger this (shockwave for example is a reliable testcase) but it can also happen during heavy cpu load, killed sub processes, and heavy flash use in multiple tabs.

Looking at WM_DWMNCRENDERINGCHANGED, there's nothing on the stack when we receive it that indicates the source. I've experimented a bit with resetting this setting when it changes, but this had no effect.

cc'ing johnath & beltzner. Is there anyone we might be able to ping to get some visibility on why windows might do this?
This seems to be a per window failure. A new window is absolutely fine. Is there any way we can notice and magically re-assign the contents to a new working window when this happens?
(In reply to comment #81)
> This seems to be a per window failure. A new window is absolutely fine. Is
> there any way we can notice and magically re-assign the contents to a new
> working window when this happens?

Hmm, I'd like to know what the dwm doesn't like about our window and the contents first.
blocking2.0: final+ → betaN+
(In reply to comment #66)
> What I'm looking for here is reproducible cases on sites, plugins, or computer
> actions. Specific STR would be most helpful.

my cases are reliable STR's.
(In reply to comment #84)
> (In reply to comment #66)
> > What I'm looking for here is reproducible cases on sites, plugins, or computer
> > actions. Specific STR would be most helpful.
> 
> my cases are reliable STR's.

I looked at crunchyroll.com and myfreecams.com but wasn't able to reproduce there. (myfreecams isn't the best test case anyway since it's nsfw.)

A hung message queue will definitely bring up a aero ghost window, but the app should recover from that without bringing glass down permanently.
on crunchroll, start watching the video then scroll up and down a few times with the scroll wheel.
ok, this seems to be reproducible in 3.6, i'll verify in 4.0 later,

This is best done from a clean cache, so the new message pop sound is not cached

open facebook and a youtube (or other) video

run the video in fullscreen and have someone message you on facebook

the flash video will exit fullscreen and hang until the pop sound plays killing aero.
ok, the new messagee appears without taking flash out of fullscreen or killing glass on 4.0
after open this website:http://calcchat.tdlc.com/free_solutions/main.html
it will hang a while and turn into fully transparent tab menu. But when open a new windows,ctrl +n , the windows will be normal
(In reply to comment #91)
> after open this website:http://calcchat.tdlc.com/free_solutions/main.html
> it will hang a while and turn into fully transparent tab menu. But when open a
> new windows,ctrl +n , the windows will be normal

That's shockwave. Odd though I can't reproduce on that page.
(In reply to comment #92)
> (In reply to comment #91)
> > after open this website:http://calcchat.tdlc.com/free_solutions/main.html
> > it will hang a while and turn into fully transparent tab menu. But when open a
> > new windows,ctrl +n , the windows will be normal
> 
> That's shockwave. Odd though I can't reproduce on that page.

Ok, on subsequent visits it happens. The first visit had to install something, and aero didn't get blown away even though the app loaded.
Depends on: 603679
Summary: Plugins kill aero glass / browser window sometimes looses aero glass effect → Plugins kill aero glass / browser window sometimes loses aero glass effect
Attached patch hack fix (obsolete) — — Splinter Review
So I've been trying to find the source of this for a while now, and really haven't come up with much. I suspect this has something to do with our oopp deferred processing, which mucks with the order of events. I've tried disabling all sorts of code, breaking the parent chain on the plugin window, hooking various dwm calls, etc.. Nothing helped track down the source of this. Without any information on why this event is generated, it's hard to say what's going on. 

I'm going to go ahead and open up a support ticket with ms tomorrow, hopefully they'll have some answers.
Attached patch hack fix (obsolete) — — Splinter Review
correct patch
Attachment #482763 - Attachment is obsolete: true
(In reply to comment #96)
> *** Bug 603384 has been marked as a duplicate of this bug. ***

Steps to Reproduce:
- Head over to http://www.3fm.nl
- Click the "Social Radio Webcam >" top left.
- Leave the windows open for a while, and voila.
Actual Results:  
After some time, the 3fm social radio window has a basis theme, while other
FF4b6 windows have my normal aero theme. No Windows 7 warning for reverting to
a more basic theme was displayed.
I can replicate this bug using the DivX web player, popping out the player window, and maximizing on any available screen.
Blocks: 604049
Attached patch sync paint patch v.1 — — Splinter Review
Making progress, this event triggers other synchronous events that we potentially defer the delivery of. Still waiting on some detail from ms as to why aero shuts down, but I've confirmed "dumping" this event if we receive it in our deferred event processing fixes the shockwave case.
Attachment #482765 - Attachment is obsolete: true
Comment on attachment 483243 [details] [diff] [review]
sync paint patch v.1

simple patch, drop this event on the floor so it can't bring down aero.
Attachment #483243 - Flags: review?(bent.mozilla)
Details: in processing wm_syncpaint, def windows proc sends pre/post events down to the theme library asking if it handled an wm_ncpaint event during the processing of wm_syncpaint. If the theme library responds back saying it didn't the window is exiled from the dwm.

This explains why this can may happen randomly on any plugin, not just shockwave. It could be triggered any time we happen to trap the sync paint + ncpaint events in deferred message processing.
Comment on attachment 483243 [details] [diff] [review]
sync paint patch v.1

Excellent! How did you figure this out? Support ticket?
Attachment #483243 - Flags: review?(bent.mozilla) → review+
(In reply to comment #102)
> Comment on attachment 483243 [details] [diff] [review]
> sync paint patch v.1
> 
> Excellent! How did you figure this out? Support ticket?

Yep. Currently waiting on some additional feedback to confirm this is the only case where the theme library is queried like this.
No longer blocks: 578165
http://hg.mozilla.org/mozilla-central/rev/7a19236fc954
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Attachment #483243 - Flags: approval1.9.2.12?
for 1.9.2 drivers, risk: low, this event rarely gets caught in 3.6 and the change isn't expected to have any negative side effects. reward: high, random shutdown of aero glass on the fx window in 3.6 when this gets hit.
No longer blocks: 579228
"for 1.9.2 drivers, risk: low, this event rarely gets caught in 3.6 and the
change isn't expected to have any negative side effects. reward: high, random
shutdown of aero glass on the fx window in 3.6 when this gets hit."

Actually, Performance degrades after a period of time where Glass is left dead on 3.x
oh wait, lol nvm, now i understand what you're saying (brain woke up)
With the latest nightly that contains this fix if i go to the bug url, or any other page that caused this problem (like the shockwave test page), the plug-in content is not displayed.
The issue has been confirmed by other users on mozillazine, should a new bug be filed or will this one be reopened?
(In reply to comment #111)
> With the latest nightly that contains this fix if i go to the bug url, or any
> other page that caused this problem (like the shockwave test page), the plug-in
> content is not displayed.
> The issue has been confirmed by other users on mozillazine, should a new bug be
> filed or will this one be reopened?

bug 603679, which is blocking this one. Shockwave is currently busted on trunk.
the problem still remain.
> the problem still remain.
Give a testcase as the URL you gave in comment 91 does not work because of bug 603379
when i open the facebook chat and type something, it will lag for a moment and when it stable , the aero glass is gone. i dunnoe why it wil lag for a moment and i cant reproduce now.
i posted about facebook further up the comment list, its the same reason.
(In reply to comment #115)
> when i open the facebook chat and type something, it will lag for a moment and
> when it stable , the aero glass is gone. i dunnoe why it wil lag for a moment
> and i cant reproduce now.

It loads flash so it can play sounds. If you still see this in a latest nightly please post back. I tried to reproduce but didn't see it.
Attached patch deliver nc paint patch — — Splinter Review
Lets augment what already landed with this - pass wm_ncpaint to DefWindowProc. MS was "pretty sure" sync paint was the only place where they do this detection. If they are doing it in other places or in some other way, a blocked wm_ncpaint would be the trigger.
Attachment #483845 - Flags: review?(bent.mozilla)
Comment on attachment 483845 [details] [diff] [review]
deliver nc paint patch

Wait... Won't this trigger painting while we're in a sync IPC call?
(In reply to comment #119)
> Comment on attachment 483845 [details] [diff] [review]
> deliver nc paint patch
> 
> Wait... Won't this trigger painting while we're in a sync IPC call?

we trap wm_paint in here, I don't think so.
(In reply to comment #120)
> (In reply to comment #119)
> > Comment on attachment 483845 [details] [diff] [review] [details]
> > deliver nc paint patch
> > 
> > Wait... Won't this trigger painting while we're in a sync IPC call?
> 
> we trap wm_paint in here, I don't think so.

I suppose it could potentially trigger a sync event to the other process, hard to say honestly. I would think all that happens is a paint of any invalid area on the window frame.
(In reply to comment #120)
> we trap wm_paint in here, I don't think so.

Well, I'm a little out of the loop when it comes to painting, but we manually paint our frame now (for the firefox button), right? Is that process somehow disconnected from a WM_NCPAINT event?
(In reply to comment #122)
> (In reply to comment #120)
> > we trap wm_paint in here, I don't think so.
> 
> Well, I'm a little out of the loop when it comes to painting, but we manually
> paint our frame now (for the firefox button), right? Is that process somehow
> disconnected from a WM_NCPAINT event?

Yes, we extend the client area for that, that's handled on a normal paint. Windows still handles the remaining nc area painting.

I'll email MS on this. The guy I was working with suggested we try to avoid blocking the nc paint events if we could, and he was also quite familiar with the synchronous event problems we ran into.
Comment on attachment 483845 [details] [diff] [review]
deliver nc paint patch

removing review request until I hear back from ms.
Attachment #483845 - Flags: review?(bent.mozilla)
We will let this bake a little more on trunk before we pull it back to branches. Also, is attachment 483845 [details] [diff] [review] needed for a complete fix?
(In reply to comment #125)
> We will let this bake a little more on trunk before we pull it back to
> branches. Also, is attachment 483845 [details] [diff] [review] needed for a complete fix?

Nope.
No longer blocks: 604049
It's not fixed.

Reproduction steps (Norton required):

1. Update the nightly build
2. Open a page with plugins, e.g. YouTube
3. Norton will pop up a message warning that you're one of the first ones trying to load plugin-container.exe
4. Answer yes (perhaps wait a little bit before answering yes)

...and Aero Glass is dead.
is the firefox/minefield gui "hung" while the norton prompt is up?
Yes, "not responding".
(In reply to comment #135)
> It's not fixed.
> 
> Reproduction steps (Norton required):
> 
> 1. Update the nightly build
> 2. Open a page with plugins, e.g. YouTube
> 3. Norton will pop up a message warning that you're one of the first ones
> trying to load plugin-container.exe
> 4. Answer yes (perhaps wait a little bit before answering yes)
> 
> ...and Aero Glass is dead.

Norton should have added Mozilla's plugin container to some sort of "ok" list. Maybe we need 3rd party out reach on this.

Regardless, if they lock up our event dispatch loop for an extended period of time windows will either display the 'ghost' aero basic window or shut down aero glass. This seems more like a bug in Norton, not Fx.

(In reply to comment #124)
> Comment on attachment 483845 [details] [diff] [review]
> deliver nc paint patch
> 
> removing review request until I hear back from ms.

FWIW, my ms contact is on vacation this week so this will have to wait a bit. I think if there are any corner cases left where aero shuts down this will address them. Although I doubt this would fix the Norton modal dialog problem.
Norton may have the release / beta Firefox on "ok list", but Minefield is not. Firefox.exe (Minefield) is deleted by Norton Sonar about every second update.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101019 Firefox/4.0b8pre

still crashes with latest trunk

happened when i tried to restore a maximized window dragging the titlebar (windows 7)
Attached image crash on 20101019 —
problem remain when restore the tab and there is a chat on my facebook.
fyi; I tested Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre and the reproduction steps mentioned in comment 97 now lead to a properly themed window without aero dropping out :)
Yeah we're not quite done here. The second patch should address remaining issues, but I need to wait on some feedback from ms.

I'll fire off a try build with that, maybe folks who can still reproduce this reliably can test the second fix for us.
for me the problem still there, when i opened a flash contained website(juz a small and simple flash calender ),it will hang a while and after that the aero gone.
(In reply to comment #146)
> for me the problem still there, when i opened a flash contained website(juz a
> small and simple flash calender ),it will hang a while and after that the aero
> gone.

Does it recover after the hang goes away?
(In reply to comment #147)
> (In reply to comment #146)
> > for me the problem still there, when i opened a flash contained website(juz a
> > small and simple flash calender ),it will hang a while and after that the aero
> > gone.
> 
> Does it recover after the hang goes away?

recover, but the aero gone.
Jim, the trunk nightly builds seemed to lower the frequency with which I was encountering this problem but not eliminate it.  With your try server build from comment 148, I haven't been able to reproduce at all. What's changed in the try server build?
(In reply to comment #150)
> Jim, the trunk nightly builds seemed to lower the frequency with which I was
> encountering this problem but not eliminate it.  With your try server build
> from comment 148, I haven't been able to reproduce at all. What's changed in
> the try server build?

It has the "deliver nc paint patch" in it. I'm waiting on some feedback from ms before I consider pushing it.

Please run that build as much as you can looking for the bug. The more data we have indicating it's the final fix we need the better.
the problem still stay in 23/10 build minefield, but the frequency had lower.
the last time it happened was when i clicked on the youtube video which embedded in a website to let it open in the new tab and it hang for a while and after recover the aero gone..
I've certainly been using the build from comment 148 quite a bit this evening and not had any problems with it.
No longer blocks: 596036
Comment on attachment 483845 [details] [diff] [review]
deliver nc paint patch

Still waiting on feedback from ms. A few folks have been running this for the last week (including myself) and the results look promising.

bent, kicking off a prelim r? request making the assumption I hear back what I'm assuming will be good news - that nc paint only paints nc client areas on the window it's sent to.
Attachment #483845 - Flags: review?(bent.mozilla)
reproducible aero crash:

try to download Miranda IM, start it and maximize firefox window

now attach and detach the miranda's window to the border of the screen as long as firefox's aero crashes

(win7x64ultimate)
Attachment #483845 - Flags: review?(bent.mozilla) → review+
Shouldn't the status be "Reopened" until fixed?  Won't get as many duplicates this way.
(In reply to comment #159)
> reproducible aero crash:
> 
> try to download Miranda IM, start it and maximize firefox window
> 
> now attach and detach the miranda's window to the border of the screen as long
> as firefox's aero crashes
> 
> (win7x64ultimate)


on lightweight pages does not work... probably it is related to flash plugin
You can get Shockwave working with these instructions:

https://bugzilla.mozilla.org/show_bug.cgi?id=603679#c35

Aero is still crashing.
blocking2.0: betaN+ → beta7+
Attachment #483845 - Flags: approval1.9.2.13?
(In reply to comment #165)
> *** Bug 608503 has been marked as a duplicate of this bug. ***
Comment 160?
https://bugzilla.mozilla.org/show_bug.cgi?id=545892#c160
(In reply to comment #166)
> (In reply to comment #165)
> > *** Bug 608503 has been marked as a duplicate of this bug. ***
> Comment 160?
> https://bugzilla.mozilla.org/show_bug.cgi?id=545892#c160

Bug 608503 sounded like a dupe. (It was filed using google translate though so I may have misinterpreted it.) This bug is considered fixed. We have one other remaining open bug related to this revolving around crashing nvidia drivers (bug 608515). If you are still seeing this and have a reliable to way to reproduce it please file a new bug.
Comment on attachment 483243 [details] [diff] [review]
sync paint patch v.1

Approved for 1.9.2.13, a=dveditz for release-drivers
Attachment #483243 - Flags: approval1.9.2.13? → approval1.9.2.13+
Comment on attachment 483845 [details] [diff] [review]
deliver nc paint patch

Approved for 1.9.2.13, a=dveditz for release-drivers
Attachment #483845 - Flags: approval1.9.2.13? → approval1.9.2.13+
Blocks: 598584
No longer blocks: 598584
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.