1348629 - Zero sized Flash content does not load on 64 bit Firefox

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect, P1)

Description

[Alice0775 White]

Affected : 64bit Firefox
Not affected : 32bit Firefox


Steps to reproduce:
1. Open https://fauux.neocities.org/Love.html

Comment 1

[Jan Sonntag]

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Flash Version: 25.0.0.127

I don't hear any sound when I open your linked page but there is no problem with other sites (e.g.: http://musicofnature.org/songsofinsects/flashtest/index.html). There was no issue in IE.

The affected flash file is located under https://fauux.neocities.org/BONPONT.swf and seems not to load properly.

Disabling e10s does not change anything.

Comment 2

[Jan Sonntag]

(In reply to Jan Sonntag from comment #1)
> Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
> Flash Version: 25.0.0.127
> 
> I don't hear any sound when I open your linked page but there is no problem
> with other sites (e.g.:
> http://musicofnature.org/songsofinsects/flashtest/index.html). There was no
> issue in IE.
> 
> The affected flash file is located under
> https://fauux.neocities.org/BONPONT.swf and seems not to load properly.
> 
> Disabling e10s does not change anything.

Comment 3

[Alice0775 White]

Setting css |object,embed {height:1px; width:1px}| to the URL page fixes the problem.

So, On 64bit Firefo, zero sized Flash plugin fails to load.

Comment 4

[Benjamin Smedberg]

We've had issues with this before, but I can't find the bug. IIRC it was that we know we don't need to paint 0-size plugins, so we never send a NPP_SetWindow, and that causes Flash not to do some set of initialization. IIRC we have an "artificial" NPP_SetWindow call somewhere.

Stefan or alice, it's worth figuring out whether this also affects win32, whether sandboxing affects this, or whether async drawing affects this.

NI?cpeterson for tracking win64 and/or async drawing.

Comment 5

[Chris Peterson [:cpeterson]]

Jim, this bug sounds like the cause of youngjump.jp bug 1323403 or Kongregate bug 1314491. We had attributed the youngjump.jp bug to a syntax error in the site's CSS, but fixing this bug would probably fix that site.

P1 because loading 0-sized Flash is important for sites that still use Flash for playing audio or accessing the clipboard.

Comment 6

[Jim Mathies [:jimm]]

tracy, could you please test the test case here to try to reproduce, and also check to see if this work around solves the issues with bug 1314491 and bug 1323403.

Comment 7

[Jim Mathies [:jimm]]

also, please test for 32-bit vs. 64-bit differences.

Comment 8

[Stefan [:StefanG_QA]]

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0

I was able to reproduce the issue on Latest Nightly build and Firefox Developer Edition at the initial link from Alice. 
However flipping the prefs for e10s or asyncdrawing does not make any difference. 

I did not encounter the issue on any 32 bits distributions.
All other links are working correctly for me (Flash loads and has sound).

Comment 9

[Tracy Walker [:tracy]]

Confirmed; setting css |object,embed {height:1px; width:1px}| works around the issue on latest 64bit Nightly for the reported site here and youngjump.jp of bug 1323403 

As far as https://fauux.neocities.org/BONPONT.swf goes, just reloading the page made the audio play there, without the css workaround.

I can't get the kongregate game to successfully load in the first steps of the STR's in bug 1314491.

Comment 10

[Jim Mathies [:jimm]]

This impacts older 64-bit releases due to our forcing windowless in those builds. It's not tied directly to the async drawing work but will impact it, and as cpeterson points out fixing this may help address other async drawing bugs. So we should block on it.

Comment 11

[Jim Mathies [:jimm]]

For me this is a regression in both 32 and 64 bit builds. 0x0 pixel flash doesn't load properly. I've been able to hack around this but the steps I needed had me thinking this might be default behavior. Turns out this is a general regression in 55 on sites like https://fauux.neocities.org/Love.html. tracy, could the intersection observer work be at play here? Can you track down a regression range too please?

Comment 12

[Jim Mathies [:jimm]]

I wonder if maybe there are two regressions here, the long standing 64-bit regression associated with windowless and a recent regression on 32-bit?

Comment 13

[Jim Mathies [:jimm]]

Attachment: BONPONT.swf

Comment 14

[Jim Mathies [:jimm]]

Attachment: test case

Comment 15

[Jim Mathies [:jimm]]

nm, I switched my taskbar shortcut to 64-bit recently and forgot.

Comment 16

[Jim Mathies [:jimm]]

Attachment: 32/64 bit logging differences

This looks like a bug on adobe's side unfortunately. We appear to be handling things the same for both 32 and 64 bit.

Comment 17

[Benjamin Smedberg]

Yes, we are sending a NPP_SetWindow call with the proper 0x0 boundaries. Jim are you going to follow up with Adobe?

Comment 18

[Tracy Walker [:tracy]]

intersectionObserver work was my initial thought too, when this came across my desk last week.  Trying with dom.IntersectionObserver.enabled set to 'false' (default for 90%) was the first thing I checked.  Double checking this morning, the minimized test case in comment 14 failed to load audio (in 0x0) with the config enabled and with it disabled.

Comment 19

[Jim Mathies [:jimm]]

(In reply to Benjamin Smedberg [:bsmedberg] from comment #17)
> Yes, we are sending a NPP_SetWindow call with the proper 0x0 boundaries. Jim
> are you going to follow up with Adobe?

yep, fired off an email this morning.

Comment 20

[Julien Cristau [:jcristau]]

Mass wontfix for bugs affecting firefox 52.

Comment 21

[Jim Mathies [:jimm]]

Current status here -

32-bit builds leverage the flash security sandbox, 64-bit builds use the Firefox plugin sandbox. The Flash sandbox does parameter checking/touchup work on SetWindow calls. This parameter touch up work facilitates successful SetWindow call handling in 32-bit flash, where as in 64-bit without the touch up work SetWindow calls apparently fail. This is what prevents Flash from fully loading, which is the reason why the test case here fails to play any music. Note this 'bug' only impacts 0x0 pixel flash.

for testing, you can reproduce the 64-bit behavior in 32-bit builds by disabling the flash sandbox.  

Still discussing with Adobe about who should fix this.

Comment 22

[Paul Goldberg]

This is a Flash related issue with Firefox 64 bit accessing Comcast Xfinity recorded content and also for me severe performance issues using Flash on my laptop with 8GB of ram. Please refer to this: https://bugzilla.mozilla.org/show_bug.cgi?id=1334803

Comment 23

[Chris Peterson [:cpeterson]]

(In reply to Paul Goldberg from comment #22)
> This is a Flash related issue with Firefox 64 bit accessing Comcast Xfinity
> recorded content and also for me severe performance issues using Flash on my
> laptop with 8GB of ram. Please refer to this:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1334803

I don't think this zero-sized Flash bug is related to the Xfinity video problems. I added some notes in bug 1334803 comment 10.

Comment 24

[Jim Mathies [:jimm]]

Hey Tracy, could you please test this using the Adobe York beta and see if they have the fix in that release.

"beta release of Flash Player 26, code named York."
http://labs.adobe.com/technologies/flashruntimes/flashplayer/

Comment 25

[Paul Goldberg]

I tried the beta flash with Firefox 54 Beta 5 with recorded content and it did not work.

Build number
    289
OS
    Windows 10
Browser
    Firefox 54.0
Flash version
    26.0.0.94
Status
    in home
Entitlements
    cvod, tve-linear, cdvr, est, tve-vod, clinear
Last fingerprint
    cloudtv_web_polymer_0_prod_1494028349792_54933
Stream provider
    primetime
Video ID
    V5665524847818291719L200813180505040017
Media ID
    comcast:dvr:schedule:V5665524847818291719L200813180505040017
Error code
    102100.33
Error description
    Loading of the specified resource has failed
Error aux info
    https://xtvapi.cloudtv.comcast.net/recording/V5665524847818291719L200813180505040017/stream.m3u8?recorderManager=cdvr-c-rmID-mana01
Video Provider
    H&I
Video Source
    s:VideoObject/Recording
Video Title
    Regeneration

Comment 26

[Chris Peterson [:cpeterson]]

Adobe's fix for the zero-sized Flash pixels won't be available until their June release of Flash 26.

Comment 27

[Paul Goldberg]

Hopefully Adobe's fix will resolve the problem.  But I assume a similar version of Flash is in Chrome and Edge and they work without any problems.  Also in Firefox 64 bit as I previously stated on my lower end laptop (which still well exceeds Flash requirements) the playback of Flash content uses considerably more of my CPU and on Xfinity TV in is about 100% CPU usage with consistent stuttering and freezing of the content. Using Chrome 64 bit or Edge the CPU usage is in the 50 to 60 percent range with no playback problems.

Comment 28

[Jim Mathies [:jimm]]

(In reply to Paul Goldberg from comment #27)
> Hopefully Adobe's fix will resolve the problem.  But I assume a similar
> version of Flash is in Chrome and Edge and they work without any problems. 
> Also in Firefox 64 bit as I previously stated on my lower end laptop (which
> still well exceeds Flash requirements) the playback of Flash content uses
> considerably more of my CPU and on Xfinity TV in is about 100% CPU usage
> with consistent stuttering and freezing of the content. Using Chrome 64 bit
> or Edge the CPU usage is in the 50 to 60 percent range with no playback
> problems.

FYI, this particular bug is unrelated to the playback problem with the Xfinity service.

Comment 29

[Jim Mathies [:jimm]]

(In reply to Chris Peterson [:cpeterson] from comment #26)
> Adobe's fix for the zero-sized Flash pixels won't be available until their
> June release of Flash 26.

I'd like tracy to confirm it's not in the upcoming may point release just to be sure.

Comment 30

[Tracy Walker [:tracy]]

With latest 64bit Nightly (20170508030204) on Win 10 Surface Pro using Shockwave Flash 26.0.0.94 (their latest beta) 0x0 flash content plays as expected.  Confirmed using attach test cases in comment 13 and 14.

Comment 31

[Jim Mathies [:jimm]]

WFM is Flash beta "York" version 26.