Closed Bug 648277 Opened 13 years ago Closed 13 years ago

Flash fails to paint until mouse is moved

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox5- fixed)

Status:
VERIFIED FIXED
Milestone:
mozilla6
Tracking Flags:
Tracking Status
firefox5 - fixed

People

(Reporter: deleeuw+bugzilla, Assigned: roc)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file)

fix
852 bytes, patch
tnikkel
: review+
asa
: approval-mozilla-aurora+
asa
: approval-mozilla-beta+
Details | Diff | Splinter Review 
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.
Confirming with build: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0) Gecko/20100101 Firefox/4.0
I can reproduce on Fedora 12.
Status: UNCONFIRMED → NEW
Component: IPC → Plug-ins
Ever confirmed: true
OS: Windows 7 → All
QA Contact: ipc → plugins
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.
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?
Severity: major → normal
Keywords: regression
Version: unspecified → Trunk
I suspect bug 605618 or bug 619176.  stechz, romaxa, thoughts?
I know little about Flash. Does Flash use nsGfxScrollFrames at all in the plugin process?
It does not.
Similar (or even the same) issue: bug 651999
stechz, are you working on this?
Blocks: 651999
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!
Summary: Flash fails to paint until I hover on it → Flash fails to paint until mouse is moved
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.
tracking-firefox5: --- → ?
Bisecting over the csets in comment 4 would be best.
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.
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.
Blocks: 647139
Assignee: nobody → romaxa
Blocks: 619176
Keywords: regressionwindow-wanted
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.
Assignee: romaxa → roc
tracking-firefox5: + → -
(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.
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.
Attached patch fix — — Splinter Review 
I'll work on a testcase for this as well.
Attachment #531250 - Flags: review?(tnikkel)
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).
Attachment #531250 - Flags: review?(tnikkel) → review+
Correct.
Whiteboard: [needs landing]
Pushed:
http://hg.mozilla.org/mozilla-central/rev/9cfa7843408b
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [needs landing]
Target Milestone: --- → mozilla6
Blocks: 656965
Flags: in-testsuite?
No longer blocks: 656965
I don't see the problem anymore on trunk.
Status: RESOLVED → VERIFIED
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.
Attachment #531250 - Flags: approval-mozilla-aurora?
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 :-(.
Attachment #531250 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Whiteboard: [needs landing]
(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.
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 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.
Attachment #531250 - Flags: approval-mozilla-beta?
Comment on attachment 531250 [details] [diff] [review]
fix

please get this landed on Aurora and Beta ASAP. Thanks.
Attachment #531250 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Whiteboard: [needs landing]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: