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

Status: VERIFIED FIXED

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

Description

[Hong Xu]

Attachment: Screen Shot 2013-08-08 at 11.32.57 PM.png

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

Comment 1

[Hong Xu]

Since before upgrading to Firefox 23, flash works fine, so I think probably this is caused by something new in Firefox 23.

Comment 2

[Loic]

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).

Comment 3

[Paul Silaghi, QA [:pauly]]

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

Comment 4

[Steven Michaud [:smichaud] (Retired)]

Sounds like a dup of bug 897814.

But Hong, please do look for that regression range, and comment about it here.

Comment 5

[Scoobidiver (away)]

(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.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #5)

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

Are you thinking about some other bug?

Comment 7

[Hong Xu]

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

Comment 8

[Steven Michaud [:smichaud] (Retired)]

(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.

Comment 9

[Steven Michaud [:smichaud] (Retired)]

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?

Comment 10

[Steven Michaud [:smichaud] (Retired)]

> And if not

And if so :-)

Comment 11

[Scoobidiver (away)]

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

Comment 12

[Steven Michaud [:smichaud] (Retired)]

(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.

Comment 13

[Steven Michaud [:smichaud] (Retired)]

> even though they happen more often with the patch for bug 873379

even though they happen more often with the patch for bug 873378

Comment 14

[Hong Xu]

(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.

Comment 15

[Hong Xu]

More Info: Reinstalling the flash player does resolve the problem.

Comment 16

[Hong Xu]

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.

Comment 17

[Loic]

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.

Comment 18

[Hong Xu]

The result is:

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

Narrowed changeset range from af4e3ce8c487 to bf73e10f5e54

Comment 19

[Scoobidiver (away)]

(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.

Comment 20

[Hong Xu]

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.

Comment 21

[Hong Xu]

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

Comment 22

[Scoobidiver (away)]

(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).

Comment 23

[Georg Fritzsche [:gfritzsche]]

(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".

Comment 24

[Hong Xu]

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".

Comment 25

[Scoobidiver (away)]

(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)?

Comment 26

[Hong Xu]

(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

Comment 27

[Hong Xu]

Another info: not only flash has this problem, java applet also has this problem.

Comment 28

[Georg Fritzsche [:gfritzsche]]

(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 :)

Comment 29

[Georg Fritzsche [:gfritzsche]]

Also: Hong Xu, i assume you are also using a retina display?

Comment 30

[Hong Xu]

(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.

Comment 31

[Georg Fritzsche [:gfritzsche]]

Thanks.

Bug 907746 might be a similar or the same issue, but it's suspected to have broken only recently.

Comment 34

[Milan Sreckovic [:milan] (needinfo for best results)]

Bug 907792 has more conversation on the fix, so I'll duplicate this one to it.

Comment 35

[Georg Fritzsche [:gfritzsche]]

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).

Comment 36

[Milan Sreckovic [:milan] (needinfo for best results)]

Does the problem go away if you set layers.use-deprecated-textures to true and restart?

Comment 37

[Richard Newman [:rnewman]]

Setting known 'affected' flags.

Comment 38

[Richard Newman [:rnewman]]

(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.

Comment 39

[Mike Connor [:mconnor]]

I can confirm rnewman's experience.  (13" Retina MBP)

Comment 40

[Georg Fritzsche [:gfritzsche]]

Are those confirmations on Nightly or 22 & 23?

Comment 41

[Richard Newman [:rnewman]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #40)
> Are those confirmations on Nightly or 22 & 23?

Current Nightly.

Comment 42

[Georg Fritzsche [:gfritzsche]]

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?

Comment 44

[Milan Sreckovic [:milan] (needinfo for best results)]

(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).

Comment 45

[schwientek]

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.

Comment 46

[Jefferson]

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.

Comment 47

[Milan Sreckovic [:milan] (needinfo for best results)]

Right, if this is about disabled hardware acceleration, then it depends on bug 900640.

Comment 48

[Richard Newman [:rnewman]]

Disabling hardware acceleration was the recommended workaround for Flash performance issues on Mac (Bug 812254 Comment 4). Indeed, it's disabled for me.

Comment 49

[Benjamin Smedberg]

This seems like a pretty serious issue, given that we expose the hardware acceleration pref in UI. Who should own it?

Comment 50

[Milan Sreckovic [:milan] (needinfo for best results)]

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.

Comment 51

[Matt Woodrow (:mattwoodrow)]

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.

Comment 52

[Alex Keybl [:akeybl]]

(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.

Comment 53

[Benjamin Smedberg]

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.

Comment 54

[u279076]

I believe the regressionwindow-wanted request was satisfied a while ago. Please re-add if more precise information is needed.

Comment 55

[Matt Woodrow (:mattwoodrow)]

Attachment: Copy the whole image

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.

Comment 56

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/9c0d7b3c6fe9

Comment 57

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/9c0d7b3c6fe9

Comment 58

[Alex Keybl [:akeybl]]

(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?

Comment 59

[Matt Woodrow (:mattwoodrow)]

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

Comment 60

[Alex Keybl [:akeybl]]

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.

Comment 61

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/ed0fcc621de4
https://hg.mozilla.org/releases/mozilla-beta/rev/0acf518182af

Comment 62

[Cornel Ionce [:noni] [Hubs QA]]

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/

Comment 63

[schwientek]

On 25 beta 7 I don't experience the bug any more (hardware acceleration disabled).

Comment 64

[u279076]

(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)?

Comment 65

[Bogdan Maris, Desktop Test Engineering]

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/

Comment 66

[lastresort0700]

I tested Firefox26 beta1 and latest Aurora in Retina display.
I don't experience bugs in both of them.

Comment 67

[Bogdan Maris, Desktop Test Engineering]

(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.

Comment 68

[Mike Taylor [:miketaylr]]

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?