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)
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+
dveditz
:
approval1.9.2.13+
|
Details | Diff | Splinter Review |
1.57 KB,
patch
|
bent.mozilla
:
review+
dveditz
:
approval1.9.2.13+
|
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.
Comment 1•14 years ago
|
||
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!
Updated•14 years ago
|
Assignee: nobody → benjamin
Comment 2•14 years ago
|
||
Attachment #426848 -
Flags: review?(ted.mielczarek)
Comment 3•14 years ago
|
||
Jim tried fixing this in bug 538990, but I guess our build system foiled him.
Blocks: 538990
Comment 4•14 years ago
|
||
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+
Assignee | ||
Comment 5•14 years ago
|
||
Hmm, my local debug/opt builds of mozilla-runtime.exe have the manifest embedded, and I still see the shockwave issue.
Comment 6•14 years ago
|
||
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.
Assignee | ||
Comment 7•14 years ago
|
||
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.
Comment 8•14 years ago
|
||
Not worth spending any time on, we have bigger fish to fry.
Comment 9•14 years ago
|
||
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 10•14 years ago
|
||
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.
Comment 11•14 years ago
|
||
(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 12•14 years ago
|
||
Attachment #427800 -
Flags: review?(bugspam.Callek)
Comment 13•14 years ago
|
||
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 14•14 years ago
|
||
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+
Comment 15•14 years ago
|
||
We already have that problem. (I think it's already filed somewhere.) And yes, I care very little about srcdir builds.
Comment 18•14 years ago
|
||
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]
Comment 19•14 years ago
|
||
(In reply to comment #15) > We already have that problem. (I think it's already filed somewhere.) Bug 426888 ;-)
Comment 20•14 years ago
|
||
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
Comment 21•14 years ago
|
||
Jan, what plugins do you have installed? What websites were you viewing at the time it happened?
Comment 23•14 years ago
|
||
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: --- → ?
Comment 24•14 years ago
|
||
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!).
Comment 25•14 years ago
|
||
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.
Comment 26•14 years ago
|
||
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
Comment 27•14 years ago
|
||
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.
Assignee | ||
Updated•14 years ago
|
Summary: Shockwave kills aero glass on the browser → [OOPP] Shockwave kills aero glass / browser window sometimes looses aero glass effect
Comment 29•14 years ago
|
||
Seems like something we should fix for 1.9.3
blocking2.0: ? → final+
Keywords: regression
Assignee | ||
Updated•14 years ago
|
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
Updated•14 years ago
|
Assignee: benjamin → nobody
Comment 33•14 years ago
|
||
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: --- → ?
Comment 35•14 years ago
|
||
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).
Comment 36•14 years ago
|
||
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: ? → -
status1.9.2:
--- → wanted
Assignee | ||
Updated•14 years ago
|
Summary: [OOPP] Plugins kill aero glass / browser window sometimes looses aero glass effect → Plugins kill aero glass / browser window sometimes looses aero glass effect
Assignee | ||
Comment 37•14 years ago
|
||
We really need to track this down, it's been ignored for too long.
Assignee: nobody → jmathies
Comment 38•14 years ago
|
||
I really don't think this is a high priority right now.
Comment 39•14 years ago
|
||
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
Comment 42•14 years ago
|
||
This seems to track to 3.6.4, which makes it seem likely it's related to plugin process isolation.
Assignee | ||
Comment 43•14 years ago
|
||
(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.
Comment 47•14 years ago
|
||
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.
Comment 48•14 years ago
|
||
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.
Comment 49•14 years ago
|
||
happened to me using fx 4 b4, happened when java crashed
Comment 50•14 years ago
|
||
I am seeing the same visual symptoms as Jon Henry using Firefox 4 beta 4.
Comment 51•14 years ago
|
||
(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.
Comment 52•14 years ago
|
||
Any plugin which can effect drawing in the title bar or uses hardware acceleration can cause the glass effect to die.
Assignee | ||
Comment 53•14 years ago
|
||
(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.
Assignee | ||
Comment 54•14 years ago
|
||
(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?
Assignee | ||
Comment 55•14 years ago
|
||
(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/
Comment 56•14 years ago
|
||
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.
Comment 57•14 years ago
|
||
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?
Assignee | ||
Comment 58•14 years ago
|
||
(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.
Assignee | ||
Comment 59•14 years ago
|
||
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.)
Comment 60•14 years ago
|
||
It doesn't appear to kill 3.6.9's glass, but definitely on 4.x
Assignee | ||
Comment 61•14 years ago
|
||
(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.
Comment 62•14 years ago
|
||
ah, retested with ipc enabled. I take it adobe says theres no issue on their side then?
Comment 63•14 years ago
|
||
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.
Comment 64•14 years ago
|
||
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.
Comment 65•14 years ago
|
||
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.
Assignee | ||
Comment 66•14 years ago
|
||
What I'm looking for here is reproducible cases on sites, plugins, or computer actions. Specific STR would be most helpful.
Comment 69•14 years ago
|
||
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.
Comment 70•14 years ago
|
||
First part of testcase
Comment 71•14 years ago
|
||
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 )
Comment 76•14 years ago
|
||
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)
Comment 78•14 years ago
|
||
The only time I ever see this issue is when I forcibly kill Java.
Assignee | ||
Comment 79•14 years ago
|
||
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?
Comment 81•14 years ago
|
||
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?
Assignee | ||
Comment 82•14 years ago
|
||
(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.
Updated•14 years ago
|
blocking2.0: final+ → betaN+
Comment 84•14 years ago
|
||
(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.
Assignee | ||
Comment 85•14 years ago
|
||
(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.
Comment 86•14 years ago
|
||
on crunchroll, start watching the video then scroll up and down a few times with the scroll wheel.
Comment 88•14 years ago
|
||
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.
Comment 89•14 years ago
|
||
ok, the new messagee appears without taking flash out of fullscreen or killing glass on 4.0
Comment 91•14 years ago
|
||
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
Assignee | ||
Comment 92•14 years ago
|
||
(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.
Assignee | ||
Comment 93•14 years ago
|
||
(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.
Updated•14 years ago
|
Summary: Plugins kill aero glass / browser window sometimes looses aero glass effect → Plugins kill aero glass / browser window sometimes loses aero glass effect
Assignee | ||
Comment 94•14 years ago
|
||
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.
Assignee | ||
Comment 97•14 years ago
|
||
(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.
Comment 98•14 years ago
|
||
I can replicate this bug using the DivX web player, popping out the player window, and maximizing on any available screen.
Assignee | ||
Comment 99•14 years ago
|
||
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
Assignee | ||
Comment 100•14 years ago
|
||
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)
Assignee | ||
Comment 101•14 years ago
|
||
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+
Assignee | ||
Comment 103•14 years ago
|
||
(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.
Assignee | ||
Comment 105•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/7a19236fc954
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•14 years ago
|
Attachment #483243 -
Flags: approval1.9.2.12?
Assignee | ||
Comment 106•14 years ago
|
||
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.
Comment 108•14 years ago
|
||
"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
Comment 109•14 years ago
|
||
oh wait, lol nvm, now i understand what you're saying (brain woke up)
Comment 111•14 years ago
|
||
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?
Assignee | ||
Comment 112•14 years ago
|
||
(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.
Comment 113•14 years ago
|
||
the problem still remain.
Comment 114•14 years ago
|
||
> the problem still remain. Give a testcase as the URL you gave in comment 91 does not work because of bug 603379
Comment 115•14 years ago
|
||
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.
Comment 116•14 years ago
|
||
i posted about facebook further up the comment list, its the same reason.
Assignee | ||
Comment 117•14 years ago
|
||
(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.
Assignee | ||
Comment 118•14 years ago
|
||
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?
Assignee | ||
Comment 120•14 years ago
|
||
(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.
Assignee | ||
Comment 121•14 years ago
|
||
(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?
Assignee | ||
Comment 123•14 years ago
|
||
(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.
Assignee | ||
Comment 124•14 years ago
|
||
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)
Comment 125•14 years ago
|
||
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?
Assignee | ||
Comment 126•14 years ago
|
||
(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.
Comment 135•14 years ago
|
||
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.
Comment 136•14 years ago
|
||
is the firefox/minefield gui "hung" while the norton prompt is up?
Comment 137•14 years ago
|
||
Yes, "not responding".
Assignee | ||
Comment 138•14 years ago
|
||
(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.
Comment 140•14 years ago
|
||
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.
Comment 141•14 years ago
|
||
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)
Comment 142•14 years ago
|
||
Comment 143•14 years ago
|
||
problem remain when restore the tab and there is a chat on my facebook.
Comment 144•14 years ago
|
||
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 :)
Assignee | ||
Comment 145•14 years ago
|
||
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.
Comment 146•14 years ago
|
||
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.
Assignee | ||
Comment 147•14 years ago
|
||
(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?
Assignee | ||
Comment 148•14 years ago
|
||
Try builds with the second patch: http://ftp.mozilla.org/pub/mozilla.org/firefox/tryserver-builds/jmathies@mozilla.com-3819aa8a97cc/tryserver-win32/
Comment 149•14 years ago
|
||
(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.
Comment 150•14 years ago
|
||
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?
Assignee | ||
Comment 151•14 years ago
|
||
(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.
Comment 152•14 years ago
|
||
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..
Comment 154•14 years ago
|
||
I've certainly been using the build from comment 148 quite a bit this evening and not had any problems with it.
Assignee | ||
Comment 158•14 years ago
|
||
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)
Comment 159•14 years ago
|
||
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)
Updated•14 years ago
|
Attachment #483845 -
Flags: review?(bent.mozilla) → review+
Comment 160•14 years ago
|
||
Shouldn't the status be "Reopened" until fixed? Won't get as many duplicates this way.
Comment 161•14 years ago
|
||
(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
Comment 162•14 years ago
|
||
You can get Shockwave working with these instructions: https://bugzilla.mozilla.org/show_bug.cgi?id=603679#c35 Aero is still crashing.
Updated•14 years ago
|
blocking2.0: betaN+ → beta7+
Assignee | ||
Comment 163•14 years ago
|
||
(In reply to comment #158) > Comment on attachment 483845 [details] [diff] [review] > deliver nc paint patch http://hg.mozilla.org/mozilla-central/rev/2893b3f53b70
Assignee | ||
Updated•14 years ago
|
Attachment #483845 -
Flags: approval1.9.2.13?
Comment 166•14 years ago
|
||
(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
Assignee | ||
Comment 167•14 years ago
|
||
(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 168•14 years ago
|
||
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 169•14 years ago
|
||
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+
Comment 170•14 years ago
|
||
Comment on attachment 483243 [details] [diff] [review] sync paint patch v.1 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/eb218437f35f
Comment 171•14 years ago
|
||
Comment on attachment 483845 [details] [diff] [review] deliver nc paint patch http://hg.mozilla.org/releases/mozilla-1.9.2/rev/2cdf5c737050
Updated•14 years ago
|
status1.9.1:
--- → unaffected
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•