Closed Bug 903296 Opened 6 years ago Closed 6 years ago

With hardware acceleration off, Flash displayed only in the top left quarter on Mac OSX

Categories

(Core :: Graphics: Layers, defect, P2, major)

23 Branch
x86
macOS
defect

Tracking

()

VERIFIED FIXED
mozilla27
Tracking Status
firefox22 --- unaffected
firefox23 --- wontfix
firefox24 - wontfix
firefox25 + verified
firefox26 + verified
firefox27 --- verified

People

(Reporter: hong, Assigned: mattwoodrow)

References

(Depends on 1 open bug)

Details

(Keywords: regression)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130730113002

Steps to reproduce:

Open any site with flash (such as any youtube video)


Actual results:

Only a small square (upleft corner) is displayed.


Expected results:

All the flash area should be displayed
Since before upgrading to Firefox 23, flash works fine, so I think probably this is caused by something new in Firefox 23.
Severity: normal → major
Yes, it sounds like a regression in FF23. On a French forum, another user using FF23 on OSX 10.8 reported the same issue, see http://forums.mozfr.org/viewtopic.php?f=5&t=114112.

Hong, could you install and use the tool mozregression (see http://harthur.github.io/mozregression/ for details) to find a possible regression range, please.
FF23 builds started in April 2013, so run "mozregression --good=2013-04-01" and post the output of the console (date/pushlog).
Component: Untriaged → Plug-ins
Flags: needinfo?(hong)
Product: Firefox → Core
Summary: Flash cannot display correctly in Firefox 23 → Flash displayed only in the top left quarter in Firefox 23 on Mac OSX
Cannot reproduce FF 23 Mac OS X 10.8.4.
Hong, please check if the issue occurs using Firefox in safe mode (with your addons disabled):
http://support.mozilla.com/kb/Safe+Mode
Sounds like a dup of bug 897814.

But Hong, please do look for that regression range, and comment about it here.
(In reply to Steven Michaud from comment #4)
> Sounds like a dup of bug 897814.
That bug was a regression from the first patch of bug 873378 that landed in 25.0a1 so unrelated.
Nevertheless, despite the backout of bug 873378's first patch, a patch for bug 896250 landed in 25.0 so there might be an underlying issue. See also bug 896250 comment 45.
(In reply to comment #5)

Bug 897814 has no established blame, and is currently marked WORKSFORME.

Are you thinking about some other bug?
First, this bug is still reproduceable in safe mode.

And the output of mozregression:

Downloading nightly from 2013-06-05
Installing nightly
2013-08-09 09:26:11.010 hdiutil[941:707] Error loading /Library/Plug-ins/DiskImages/VirtualPCDiskImagePlugin.bundle/Contents/MacOS/VirtualPCDiskImagePlugin:  dlopen(/Library/Plug-ins/DiskImages/VirtualPCDiskImagePlugin.bundle/Contents/MacOS/VirtualPCDiskImagePlugin, 262): no suitable image found.  Did find:
	/Library/Plug-ins/DiskImages/VirtualPCDiskImagePlugin.bundle/Contents/MacOS/VirtualPCDiskImagePlugin: mach-o, but wrong architecture
2013-08-09 09:26:11.011 hdiutil[941:707] Cannot find function pointer MacDiskImagePluginFactory for factory 7F1FD83E-6684-11D8-968F-000A957703C0 in CFBundle/CFPlugIn 0x7fcd0be01f30 </Library/Plug-ins/DiskImages/VirtualPCDiskImagePlugin.bundle> (bundle, not loaded)
2013-08-09 09:26:33.001 hdiutil[960:707] Error loading /Library/Plug-ins/DiskImages/VirtualPCDiskImagePlugin.bundle/Contents/MacOS/VirtualPCDiskImagePlugin:  dlopen(/Library/Plug-ins/DiskImages/VirtualPCDiskImagePlugin.bundle/Contents/MacOS/VirtualPCDiskImagePlugin, 262): no suitable image found.  Did find:
	/Library/Plug-ins/DiskImages/VirtualPCDiskImagePlugin.bundle/Contents/MacOS/VirtualPCDiskImagePlugin: mach-o, but wrong architecture
2013-08-09 09:26:33.002 hdiutil[960:707] Cannot find function pointer MacDiskImagePluginFactory for factory 7F1FD83E-6684-11D8-968F-000A957703C0 in CFBundle/CFPlugIn 0x7f9d6860a470 </Library/Plug-ins/DiskImages/VirtualPCDiskImagePlugin.bundle> (bundle, not loaded)
hdiutil: couldn't unmount "disk1" - Resource busy
Traceback (most recent call last):
  File "/usr/local/bin/mozregression", line 9, in <module>
    load_entry_point('mozregression==0.6.4', 'console_scripts', 'mozregression')()
  File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mozregression/regression.py", line 187, in cli
    bisector.bisect(get_date(options.good_date), get_date(options.bad_date))
  File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mozregression/regression.py", line 108, in bisect
    dest = self.runner.start(midDate)
  File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mozregression/runnightly.py", line 234, in start
    if not self.install(date):
  File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mozregression/runnightly.py", line 231, in install
    return self.app.install()
  File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mozregression/runnightly.py", line 75, in install
    MozInstaller(src=self.dest, dest="moznightlyapp", dest_app="Mozilla.app")
  File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mozregression/mozInstall.py", line 159, in __init__
    self.installDmg(self.dest_app)
  File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/mozregression/mozInstall.py", line 205, in installDmg
    subprocess.check_call(["hdiutil", "detach", mountpoint], stdout=devnull)
  File "/usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/lib/python2.7/subprocess.py", line 542, in check_call
    raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['hdiutil', 'detach', 'moznightlyapp/MOUNTEDDMG']' returned non-zero exit status 16
Exception OSError: (30, 'Read-only file system', 'moznightlyapp/MOUNTEDDMG') in <bound method FirefoxNightly.cleanup of <mozregression.runnightly.FirefoxNightly object at 0x103510f50>> ignored
Flags: needinfo?(hong)
(In reply to comment #7)

As best I can tell, the mozregression tool didn't work properly for you.  I don't know why.

Do you know where the copy of Python you have in /usr/local/Cellar/ came from?

Also, do you know why something is trying to load a "disk image" from /Library/Plug-ins/DiskImages?

I don't know much about the mozregression tool, but I don't think either of these is associated with it.
Heather, if I remember right you're the author of the mozregression tool.

Am I right that the output from comment #7 isn't "normal"?  And if not, do you have any idea what might have caused it?
Flags: needinfo?(fayearthur)
> And if not

And if so :-)
(In reply to Steven Michaud from comment #6)
> Are you thinking about some other bug?
See bug 896250 comment 45.
(In reply to comment #11)

>> Sounds like a dup of bug 897814.
> That bug was a regression from the first patch of bug 873378 that landed in
> 25.0a1 so unrelated.

OK, now I see what you're saying:  If bug 897814 was caused by bug 873378, and the patch for bug 873379 landed on mozilla-central when that represented the 26 branch, then it can't be the same as this bug -- which effects FF 23.

But the two bugs really are the same (they have exactly the same symptoms), even though they happen more often with the patch for bug 873379 than without it.

I think either this bug should be duped to bug 897814 or bug 897814 should be duped to this one, and then the "master" bug (the non-duped one) should be made to depend on bug 900640.
> even though they happen more often with the patch for bug 873379

even though they happen more often with the patch for bug 873378
(In reply to Steven Michaud from comment #8)
> (In reply to comment #7)
> 
> As best I can tell, the mozregression tool didn't work properly for you.  I
> don't know why.
> 
> Do you know where the copy of Python you have in /usr/local/Cellar/ came
> from?
> 
> Also, do you know why something is trying to load a "disk image" from
> /Library/Plug-ins/DiskImages?
> 
> I don't know much about the mozregression tool, but I don't think either of
> these is associated with it.

The python installed in /usr/local/Cellar is obtained by homebrew, which is a package manager for OS X. It works perfect for my other python usages, so I don't think this could be the source of the problem.

I don't know about this image issue either.
More Info: Reinstalling the flash player does resolve the problem.
Sorry I got it wrong. Reinstalling doesn't help.

(In reply to Hong Xu from comment #15)
> More Info: Reinstalling the flash player does resolve the problem.
Hong, could you delete Delete /Library/Plug-ins/DiskImages/VirtualPCDiskImagePlugin.bundle and restart. It's probably a remaining of Virtual PC.

A regression range would help a lot, someone needs to run it.
The result is:

Last good nightly: 2013-07-19
First bad nightly: 2013-07-20

Narrowed changeset range from af4e3ce8c487 to bf73e10f5e54
(In reply to Hong Xu from comment #18)
> The result is:
> Last good nightly: 2013-07-19
> First bad nightly: 2013-07-20
> Narrowed changeset range from af4e3ce8c487 to bf73e10f5e54
The regression range is
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=af4e3ce8c487&tochange=bf73e10f5e54
It was caused by bug 873378 that first landed in 25.0a1/20130719 and was reported in bug 869250. It was fixed by backing it out.
It means that Firefox 23.0 and 24.0 Beta are not affected. Is it true? If it isn't, go further with mozregression.
Flags: needinfo?(hong)
I tried with Firefox 24 beta1 but the issue still persists. I keep having connection issues when going further. Anyway I'll try whenever I can.
Is there a verbose mode for mozregression? I kept getting messages like this:


Last good nightly: 2013-07-19
First bad nightly: 2013-07-20

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2013-07-19&enddate=2013-07-20

do you want to bisect further by fetching the repository and building? (y or n) y
Building changesets:
Trunk not found.
Removed old mozbuild-trunk directory. Downloading a fresh repo from mozilla-central...
requesting all changes
adding changesets
adding manifests
transaction abort!
rollback completed
abort: connection ended unexpectedly
(In reply to Hong Xu from comment #21)
> Last good nightly: 2013-07-19
> First bad nightly: 2013-07-20
It's the same as the one you posted in comment 18. Try older dates like April 2013 (see https://wiki.mozilla.org/RapidRelease/Calendar).
Priority: -- → P2
Flags: needinfo?(fayearthur)
(In reply to Hong Xu from comment #21)
> transaction abort!
> rollback completed
> abort: connection ended unexpectedly

Sadly that can happen with some connections when it pulls the source repository (quite a bit of data to pull).

But as Scoobidiver says, it would be great if you could check with mozregression when this was introduced in Firefox <= 24.
I think you can just test with builds from before Fx24 landed in Aurora using "mozregression --bad=2013-06-25".
I tried mozregression --bad=2013-06-25, and I got:

Last good nightly: 2013-06-24
First bad nightly: 2013-06-25

(In reply to Georg Fritzsche [:gfritzsche] from comment #23)
> (In reply to Hong Xu from comment #21)
> > transaction abort!
> > rollback completed
> > abort: connection ended unexpectedly
> 
> Sadly that can happen with some connections when it pulls the source
> repository (quite a bit of data to pull).
> 
> But as Scoobidiver says, it would be great if you could check with
> mozregression when this was introduced in Firefox <= 24.
> I think you can just test with builds from before Fx24 landed in Aurora
> using "mozregression --bad=2013-06-25".
(In reply to Hong Xu from comment #24)
> Last good nightly: 2013-06-24
> First bad nightly: 2013-06-25
The working range is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=76820c6dff7b&tochange=bc569033125a
So it's either fixed in 25.0 or 26.0.

Can you go beyond to find a regression range instead (mozregression --bad=2013-05-13)?

(In reply to Scoobidiver from comment #25)
> (In reply to Hong Xu from comment #24)
> > Last good nightly: 2013-06-24
> > First bad nightly: 2013-06-25
> The working range is:
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=76820c6dff7b&tochange=bc569033125a
> So it's either fixed in 25.0 or 26.0.
> 
> Can you go beyond to find a regression range instead (mozregression
> --bad=2013-05-13)?

I don't think it's between this range since I got:

Last good nightly: 2013-05-12
First bad nightly: 2013-05-13

But when I ran mozregression --good=2013-04-01 I got:

Last good nightly: 2013-07-19
First bad nightly: 2013-07-20
Flags: needinfo?(hong)
Another info: not only flash has this problem, java applet also has this problem.
(In reply to Hong Xu from comment #26)
> But when I ran mozregression --good=2013-04-01 I got:

Yes, if you only provide a "--good" argument you're back to the first regression range you found.
Can you try to go up with the "--bad" date until you find a range that looks more realistic?

Also, please post the pushlog URLs too - they make it much easier to look it up :)
Also: Hong Xu, i assume you are also using a retina display?
Flags: needinfo?(hong)

(In reply to Georg Fritzsche [:gfritzsche] from comment #29)
> Also: Hong Xu, i assume you are also using a retina display?

Yes I am. I'll go with the '--bad' date.
Flags: needinfo?(hong)
Thanks.

Bug 907746 might be a similar or the same issue, but it's suspected to have broken only recently.
Duplicate of this bug: 907661
Duplicate of this bug: 907696
Status: UNCONFIRMED → NEW
Ever confirmed: true
Bug 907792 has more conversation on the fix, so I'll duplicate this one to it.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 907792
Bug 907792 is about a regression in the 2013-08-21 Nightly, this one is about an earlier issue (that apparently didn't affect everyone when comparing against the current volume of reports).
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Does the problem go away if you set layers.use-deprecated-textures to true and restart?
Setting known 'affected' flags.
(In reply to Milan Sreckovic [:milan] from comment #36)
> Does the problem go away if you set layers.use-deprecated-textures to true
> and restart?

I observed the problem, set that, restarted, and couldn't reproduce. That's not as strong as saying there's a 100% correlation, but it's a data point.
I can confirm rnewman's experience.  (13" Retina MBP)
Are those confirmations on Nightly or 22 & 23?
(In reply to Georg Fritzsche [:gfritzsche] from comment #40)
> Are those confirmations on Nightly or 22 & 23?

Current Nightly.
Is anyone affected on a release or beta build able, please test the layers.use-deprecated-textures. I think that covers what milan was asking for.

Hong Xu, can you check?
Flags: needinfo?(hong)
Duplicate of this bug: 912824
(In reply to Georg Fritzsche [:gfritzsche] from comment #42)
> Is anyone affected on a release or beta build able, please test the
> layers.use-deprecated-textures. I think that covers what milan was asking
> for.
> 

Indeed.  And we believe that problem has been solved.  This is all nightly (26).
Using 26 nigtly, the problem is still there. Only top left corner of videos are visible.

Setting or unsetting layers.use-deprecated-textures has no effect.

I'm using a Mac with Retina Display.
On SuMo, several Firefox 23 users have reported that re-enabling hardware acceleration fixes the problem for them: https://support.mozilla.org/questions/968863 

This settings difference could explain why not everyone can replicate the problem.
Right, if this is about disabled hardware acceleration, then it depends on bug 900640.
Depends on: 900640
Flags: needinfo?(hong)
Summary: Flash displayed only in the top left quarter in Firefox 23 on Mac OSX → With hardware acceleration off, Flash displayed only in the top left quarter on Mac OSX
Disabling hardware acceleration was the recommended workaround for Flash performance issues on Mac (Bug 812254 Comment 4). Indeed, it's disabled for me.
This seems like a pretty serious issue, given that we expose the hardware acceleration pref in UI. Who should own it?
Flags: needinfo?(milan)
Matt, any chance of verifying whether this is dependent on bug 900640 or not?  I thought it was, but BenWa thinks it isn't and I trust his judgment more than mine.
Component: Plug-ins → Graphics: Layers
Flags: needinfo?(milan) → needinfo?(matt.woodrow)
I think it is dependent. Inactive layers, and having hardware acceleration disabled both mean rendering via BasicLayerManager. I think that path is what's failing to account for the retina resolution.
Flags: needinfo?(matt.woodrow)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #49)
> This seems like a pretty serious issue, given that we expose the hardware
> acceleration pref in UI. Who should own it?

This is not serious enough to land in 23/24, but we would consider a 25 uplift.

https://bugzilla.mozilla.org/show_bug.cgi?id=812254#c4 was not a support article, but rather a bug comment.
I'm not sure what bug 812254 has to do with this, though... "use hardware acceleration" is a checkbox in our pref dialog, so we can't write this off as an unsupported configuration. I don't think we know how many people have that box checked.
I believe the regressionwindow-wanted request was satisfied a while ago. Please re-add if more precise information is needed.
Assignee: nobody → matt.woodrow
I also think you were probably right about this not being linked to bug 900640.

I misread the bug and thought they had the same symptoms.
Attachment #810990 - Flags: review?(bgirard)
Attachment #810990 - Flags: review?(bgirard) → review+
https://hg.mozilla.org/mozilla-central/rev/9c0d7b3c6fe9
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
(In reply to Matt Woodrow (:mattwoodrow) from comment #56)
> https://hg.mozilla.org/integration/mozilla-inbound/rev/9c0d7b3c6fe9

Low risk enough for an uplift request to Aurora/Beta?
Flags: needinfo?(matt.woodrow)
Comment on attachment 810990 [details] [diff] [review]
Copy the whole image

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Unknown, probably been broken for a long time.
User impact if declined: Only shows 1/4 of plugins when running without hardware acceleration on a HiDPI screen.
Testing completed (on m-c, etc.): Been on m-c for a while, tested locally.
Risk to taking this patch (and alternatives if risky): Very low risk.
String or IDL/UUID changes made by this patch: None
Attachment #810990 - Flags: approval-mozilla-beta?
Attachment #810990 - Flags: approval-mozilla-aurora?
Flags: needinfo?(matt.woodrow)
Comment on attachment 810990 [details] [diff] [review]
Copy the whole image

Very low risk fix to a fairly recent regression (Fx22 unaffected). Approving for branches.
Attachment #810990 - Flags: approval-mozilla-beta?
Attachment #810990 - Flags: approval-mozilla-beta+
Attachment #810990 - Flags: approval-mozilla-aurora?
Attachment #810990 - Flags: approval-mozilla-aurora+
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:25.0) Gecko/20100101 Firefox/25.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:26.0) Gecko/20100101 Firefox/26.0

WFM on Firefox 25 beta 7 (build ID: 20131010180222) and latest Aurora (build ID: 20131010004002).


Hong, could you or someone please verify to see if this is fixed on a HI-DPI display?

FF 25 beta 7: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/25.0b7-candidates/build1/

Latest aurora: ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora/
Flags: needinfo?(hong)
On 25 beta 7 I don't experience the bug any more (hardware acceleration disabled).
(In reply to schwientek from comment #63)
> On 25 beta 7 I don't experience the bug any more (hardware acceleration
> disabled).

Thanks, can you please try the latest Aurora (aurora.mozilla.org) and Nightly (nightly.mozilla.org)?
Flags: needinfo?(hong)
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:26.0) Gecko/20100101 Firefox/26.0

Works for me on Firefox 26 beta 1 (buildID: 20131028225529) and latest Aurora 27.0a2 (buildID: 20131029134505) but on a mac without a hi-dpi screen. 

Can you or anyone with a retina display please verify this is fixed on Firefox 26 beta 1 and on the builds from comment 64?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/26.0b1-candidates/build1/mac/en-US/
http://www.mozilla.org/en-US/firefox/aurora/
http://nightly.mozilla.org/
Flags: needinfo?(schwientek)
I tested Firefox26 beta1 and latest Aurora in Retina display.
I don't experience bugs in both of them.
(In reply to lastresort0700 from comment #66)
> I tested Firefox26 beta1 and latest Aurora in Retina display.
> I don't experience bugs in both of them.

Thank you. Setting this as verified on 26 and 27.
Status: RESOLVED → VERIFIED
Flags: needinfo?(schwientek)
Keywords: verifyme
See https://bugzilla.mozilla.org/show_bug.cgi?id=944541 for a report where this is happening in Nightly again. I can reproduce that bug. Possible regression?
You need to log in before you can comment on or make changes to this bug.