Last Comment Bug 648277 - Flash fails to paint until mouse is moved
: Flash fails to paint until mouse is moved
Status: VERIFIED FIXED
: regression
Product: Core
Classification: Components
Component: Plug-ins (show other bugs)
: Trunk
: x86 All
: -- normal (vote)
: mozilla6
Assigned To: Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
:
Mentors:
http://www.stockholm.se/TrafikStadspl...
: 651999 656276 656965 658008 (view as bug list)
Depends on:
Blocks: 619176 647139 651999
  Show dependency treegraph
 
Reported: 2011-04-07 08:45 PDT by Kai de Leeuw
Modified: 2011-05-23 18:09 PDT (History)
19 users (show)
roc: in‑testsuite?
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
fixed


Attachments
fix (852 bytes, patch)
2011-05-09 23:00 PDT, Robert O'Callahan (:roc) (Exited; email my personal email if necessary)
tnikkel: review+
asa: approval‑mozilla‑aurora+
asa: approval‑mozilla‑beta+
Details | Diff | Splinter Review

Description Kai de Leeuw 2011-04-07 08:45:15 PDT
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.2a1pre) Gecko/20110407 Firefox/4.2a1pre
Build Identifier: 

When I on the attached URL display a Flash movie by clicking on "Teckenspråk" it doesn't show until I move the mouse on the place where it should be.

I have confirmed that it is an issue with IPC. I have disabled IPC and then it works as it should. 

It also works in 3.6. It also works in Chrome 10.

I also have a colleague that gets the same problem on her Firefox 4 on Windows 7.

Reproducible: Always

Steps to Reproduce:
1. Load the URL in this bug
2. Press "Teckenspråk"
3. A white space opens up, in that white space, move the mouse a bit
Actual Results:  
Flash not painting itself.

Expected Results:  
Flash painting itself.
Comment 1 José Jeria 2011-04-07 08:51:08 PDT
Confirming with build: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
Comment 2 Josh Matthews [:jdm] 2011-04-07 08:54:31 PDT
I can reproduce on Fedora 12.
Comment 3 Kai de Leeuw 2011-04-07 08:55:45 PDT
My report may have been a bit confusing:

Steps to Reproduce:
1. Load the URL in this bug
2. Press "Teckenspråk"
3. A white space opens up, where a flash should be

Actual Results:  
Flash not painting itself.

Expected Results:  
Flash painting itself.

To repaint the flash move the mouse a bit.
Comment 4 (mostly gone) XtC4UaLL [:xtc4uall] 2011-04-08 07:56:35 PDT
Last good nightly: 2011-01-13 First bad nightly: 2011-01-14

Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=54184cfa6f0e&tochange=9f412256da4c

against Flash 10.3.180.65/WinXP.

=> Fallout of Bug 605618?
Comment 5 Josh Matthews [:jdm] 2011-04-08 08:22:19 PDT
I suspect bug 605618 or bug 619176.  stechz, romaxa, thoughts?
Comment 6 Benjamin Stover (:stechz) 2011-04-08 09:39:50 PDT
I know little about Flash. Does Flash use nsGfxScrollFrames at all in the plugin process?
Comment 7 Boris Zbarsky [:bz] 2011-04-08 09:47:16 PDT
It does not.
Comment 8 José Jeria 2011-04-21 15:38:19 PDT
Similar (or even the same) issue: bug 651999
Comment 9 Boris Zbarsky [:bz] 2011-04-21 17:38:29 PDT
stechz, are you working on this?
Comment 10 Benjamin Stover (:stechz) 2011-04-22 09:10:05 PDT
No, sorry, I suspected it wasn't my bug and was a regression of 619176. The cross process code I touched shouldn't have anything to do with the Flash plugin process, I think.

Chris, do you think bug 605618 could have caused this regression? If so, I can dig in though I may need some guidance!
Comment 11 Kai de Leeuw 2011-04-24 02:09:56 PDT
I think this should block fx5. 

Because it is a regression.

I also think this is a bug of major importans, not normal importance. I'll leave that up to someone else to change though.

I also think it affects a lot of pages out there. It wasn't very hard to find. And another seemingly related issue, bug 651999, has been found shortly thereafter. Potentially it affects any page with flash in it, if it has whatever  triggers the lack of invalidation of the flash plugin.
Comment 12 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-04-25 22:20:16 PDT
Bisecting over the csets in comment 4 would be best.
Comment 13 Chris Jones [:cjones] inactive; ni?/f?/r? if you need me 2011-04-27 21:18:37 PDT
The regression window is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=54184cfa6f0e&tochange=9f412256da4c .  We need that window narrowed down to the cset/bug that broke things.
Comment 14 Alice0775 White 2011-04-28 09:06:31 PDT
Regression range:
Works:
http://hg.mozilla.org/mozilla-central/rev/70d10ef482f3
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110113
Firefox/4.0b10pre ID:20110113045435
Fails:
http://hg.mozilla.org/mozilla-central/rev/17fae822d2d7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110112
Firefox/4.0b10pre ID:20110113052706
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=70d10ef482f3&tochange=17fae822d2d7

And In local build,
Regression #1 is triggered by  b9029c71a63a,
build from b9029c71a63a: fails
build from 08d4fcb4ebbf: works
Regressed by:
b9029c71a63a    Oleg Romashin — Bug 619176 - Plugins get Visible state every
time when scrolling (:BuildLayer always make them visible). r=roc a=approval2.0
#1. After clicking the button, unless the mouse pointer is moved, it does not
play back the movie.

And  this is as same as regression #1 of Bug 647139 Comment 3
This does not happen regression #2 of Bug 647139 Comment 3, because of no auto-play.
Comment 15 Alice0775 White 2011-04-28 09:09:44 PDT
*** Bug 651999 has been marked as a duplicate of this bug. ***
Comment 16 JP Rosevear [:jpr] 2011-05-04 11:39:58 PDT
Discussed in triage - not a regression from 4.0 so not tracking for 5.  This should get looked at by Roc since he reviewed the original patch and this could be nom'ed for approval if the risk is low, alternately land on m-c for 6.
Comment 17 José Jeria 2011-05-04 11:48:28 PDT
(In reply to comment #16)
> Discussed in triage - not a regression from 4.0 so not tracking for 5. 

Correct, but this is a serious regression from Firefox 3.6 that made it into Firefox 4. I find this reasoning a bit weak.
Comment 18 Boris Zbarsky [:bz] 2011-05-04 11:57:40 PDT
José, I think you're just slightly confused about what "tracked" means.  Please feel free to mail me privately if you want to talk about this.
Comment 19 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-09 23:00:17 PDT
Created attachment 531250 [details] [diff] [review]
fix

I'll work on a testcase for this as well.
Comment 20 Timothy Nikkel (:tnikkel) 2011-05-10 08:16:44 PDT
Comment on attachment 531250 [details] [diff] [review]
fix

Ah, so the desired effect of that RequestUpdatePluginGeometry call is that nsObjectFrame::ComputeWidgetGeometry gets called, not the ConfigureChildren on the parent widget (which makes no sense since this is a windowless plugin).
Comment 21 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-10 14:47:26 PDT
Correct.
Comment 22 Mounir Lamouri (:mounir) 2011-05-13 02:12:29 PDT
Pushed:
http://hg.mozilla.org/mozilla-central/rev/9cfa7843408b
Comment 23 (mostly gone) XtC4UaLL [:xtc4uall] 2011-05-14 05:00:20 PDT
*** Bug 656276 has been marked as a duplicate of this bug. ***
Comment 24 (mostly gone) XtC4UaLL [:xtc4uall] 2011-05-14 05:03:30 PDT
*** Bug 656965 has been marked as a duplicate of this bug. ***
Comment 25 Kai de Leeuw 2011-05-15 03:38:15 PDT
I don't see the problem anymore on trunk.
Comment 26 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-16 03:08:05 PDT
Comment on attachment 531250 [details] [diff] [review]
fix

Requesting Aurora approval. This is a pretty bad regression in FF4, we should fix it as soon as possible. The patch is very safe.
Comment 27 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-16 05:50:00 PDT
I tried to write a test, but I can't come up with a testcase that passes with the patch and fails without the patch :-(.
Comment 28 Thomas Ahlblom 2011-05-20 22:11:44 PDT
*** Bug 658008 has been marked as a duplicate of this bug. ***
Comment 29 Thomas Ahlblom 2011-05-20 22:26:44 PDT
(In reply to comment #27)
> I tried to write a test, but I can't come up with a testcase that passes
> with the patch and fails without the patch :-(.

Robert, what kind of testcase do you need (if it's still needed)? Manual or automatic? Maybe the one in the URL field of the duplicated bug 658008 can be used as inspiration. Or maybe even ask the reporter of that bug if he can help to adapt that testcase to your requirements.
Comment 30 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-21 06:19:09 PDT
Automatic. I have a manual testcase that works fine, I just haven't found a way to reliably automate it using our test frameworks.
Comment 31 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-22 18:24:55 PDT
http://hg.mozilla.org/releases/mozilla-aurora/rev/13f156313874
Comment 32 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-22 18:25:43 PDT
Comment on attachment 531250 [details] [diff] [review]
fix

Requesting Aurora approval. This is a pretty bad regression in FF4, we should fix it as soon as possible. The patch is very safe.
Comment 33 Asa Dotzler [:asa] 2011-05-22 19:54:17 PDT
Comment on attachment 531250 [details] [diff] [review]
fix

please get this landed on Aurora and Beta ASAP. Thanks.
Comment 34 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-05-23 18:09:24 PDT
http://hg.mozilla.org/releases/mozilla-beta/rev/0f05ac394e87

Note You need to log in before you can comment on or make changes to this bug.