1323403 - Flash Player on http://youngjump.jp/manga/kingdom/ doesn't work when Flash is windowless

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect)

Description

[Alice0775 White]

Reproducible: always

Steps to Reproduce:
1. Activate Flash Plugin 24
2. Open http://youngjump.jp/manga/kingdom/
3. Wait for few seconds

Actual Results:
Black

Expected Results:
Flash content should appear

Comment 1

[Alice0775 White]

FYI, Firefox 32bit build works as expected.

Comment 2

[Alice0775 White]

#1 Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=02c69f4f896255189ce2f9f4e0d875e383bcfbd7&tochange=a1bd47d76f71162534090485acc57866dcd55eef

Regressed by: a1bd47d76f71	David Anderson — Enable direct plugin drawing by default. (bug 1229961 part 2, r=aklotz)

#2 Regression window with forcing disable direct plugin(dom.ipc.plugins.asyncdrawing.enabled=false):
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=9c43645228d84d1eefcd03cb2944244253282f99&tochange=b71d96329d7aa31c01b13319707aa96587051f0b

Regressed by: b71d96329d7a	Makoto Kato — Bug 1246574 - Store sandbox level to nsPluginTag for e10s. r=jimm

Comment 3

[Jim Mathies [:jimm]]

This is an async painting related regression and is tracked by that project. We've limited this feature to dev channels.

Comment 4

[Benjamin Smedberg]

What about the second regression range? That seems to be affecting the non-asyncpainting codepath.

Comment 5

[Jim Mathies [:jimm]]

(In reply to Benjamin Smedberg [:bsmedberg] from comment #4)
> What about the second regression range? That seems to be affecting the
> non-asyncpainting codepath.

Yes you're right, this appears to hit 64-bit as well without async. Might have something to do with forcing windowless in 64-bit. 

Kicking this out to a new bug.

Comment 6

[Jim Mathies [:jimm]]

Confirming, this is broken in 32-bit builds w/async painting enabled.

Comment 7

[Andrew Overholt [:overholt]]

Are we letting async painting ride with 52?

Comment 8

[Benjamin Smedberg]

async painting is currently preffed to nightly/aurora only and depends on fixes from Adobe.

Comment 9

[Jim Mathies [:jimm]]

(In reply to Andrew Overholt [:overholt] from comment #7)
> Are we letting async painting ride with 52?

nope!

Comment 10

[Jim Mathies [:jimm]]

Hey Jet,

Is there someone in layout who might be able to take a look at this flash async painting bug? This isn't a flash issue, the swf in this page gets injected post page load via some js libraries. The resulting swf ends up with busted dims (page width x 0px). This is easy to see via Dev Tools Inspector. Looks like this might be a layout / js timing issue.

Note o test in nightly make sure dom.ipc.plugins.asyncdrawing.enabled=true, and this is windows only.

--

<script type="text/javascript" src="../../assets/common/js/swfobject.js"></script>
<script type="text/javascript" src="../../assets/common/js/swffit.js"></script>
<script type="text/javascript">
/*<![CDATA[*/
swfobject.embedSWF('../../assets/swf/index.swf', 'contents', '100%', '100%', '9', 
                   '../../assets/common/swf/expressinstall.swf', {domain: '*', page: 'mangaDetail', fontColor:'1'}, {allowscriptaccess: 'always', allowFullScreen: 'true', bgcolor: '#000000', menu: 'false'}, {id: 'contents', name: 'contents'});
/*]]>*/
</script>

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Async painting isn't riding the 52 train per comment 9.

Comment 12

[Alice0775 White]

(In reply to Ryan VanderMeulen [:RyanVM] from comment #11)
> Async painting isn't riding the 52 train per comment 9.

Even if disable async painting on Aurora52.0a2, the problem is reproducible
due to Bug 1246574. see comment #2.

Comment 13

[Benjamin Smedberg]

Yes, win64 is affected on all channels currently. win32 is nightly/aurora only.

Comment 14

[Astley Chen (inactive)]

(In reply to Alice0775 White from comment #12)
> (In reply to Ryan VanderMeulen [:RyanVM] from comment #11)
> > Async painting isn't riding the 52 train per comment 9.
> 
> Even if disable async painting on Aurora52.0a2, the problem is reproducible
> due to Bug 1246574. see comment #2.

Alice, per comment 2, the problem seems to be existed from Firefox 47 and regressed by:
b71d96329d7a	Makoto Kato — Bug 1246574 - Store sandbox level to nsPluginTag for e10s. r=jimm

It's supposed to be a carryover regression(47~51), not particularly for beta 51. I also tested Firefox 50.1.0 x64 on Windows 10, it looks fine either. Could you confirm again and update the status flag accordingly ? Thanks.

Comment 15

[Alice0775 White]

The problem is reproduced on Firefox50.1.0 x64.
https://hg.mozilla.org/releases/mozilla-release/rev/8612c3320053b796678921f8f23358e3e9df997e
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:50.0) Gecko/20100101 Firefox/50.0 ID:20161208153507

Comment 16

[Jet Villegas (inactive)]

Kato-san: Can you have a look here? I know that this isn't strictly due to bug 1246574 which just enables windowless for e10s, but this site is Japanese, and you're on Windows, and you've been in the plugin code, and I believe in you, and...

Please review the symptoms in comment 10 and report back. Thanks!

Comment 17

[Makoto Kato [:m_kato]]

I look this.

Comment 18

[Makoto Kato [:m_kato]]

Into Reflow into nsPluginFrame, ComuputedHeight keeps 0.  And although I copy html, scripts, and swf to local, I cannot reproduce this on local...

Comment 19

[Makoto Kato [:m_kato]]

Ah, OK.  This depends on 'position: relative;'.  'body { position: relative; }' causes this issue.

<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<style type="text/css">
html {
        height:100%:
}  /* for FF */

body {
        position: relative;
}
</style>
</head>
<body>
<object type="application/x-shockwave-flash" data="black.swf" width="100%" height="100%"
/>
</body>
</html>

Comment 20

[Makoto Kato [:m_kato]]

On normal case, index.swf requests some XML files and next swf.
When this issue occurs, at first, load index.swf.  But this height is 0px, this flash won't be activated.  So content isn't shown correctly....

Comment 21

[Makoto Kato [:m_kato]]

Even if win32, when using windowless and disabling Flash's protected mode, this occurs.
When using windowless and Flash's protected mode on Win32, NP_SetWindow will call InvalidRect.  So, mAccumulatedInvalidRect doesn't become empty, then AsyncShowPluginFrame is called.

Comment 22

[Jim Mathies [:jimm]]

Is there something we can do here to address this?

Comment 23

[Jim Mathies [:jimm]]

bsmedberg said he's like to take a look at this too.

Comment 24

[Chris Peterson [:cpeterson]]

Benjamin, have you had a chance to look at this windowless Flash bug? Do you want to delegate this bug to another developer?

Comment 25

[Benjamin Smedberg]

I will look at this time-available, but I'm not making engineering commitments.

Comment 26

[Jim Mathies [:jimm]]

Following up on what Kato had to say in comment 19. This bug is caused by a couple issues. First the web site has a bit of invalid css - 

html {
        height:100%:
}  /* for FF */

Note the colon there. This rule gets rejected by layout:

[JavaScript Warning: "Expected end of value but found ‘:’.  Error in parsing value for ‘height’.  Declaration dropped." {file: "http://youngjump.jp/assets/css/noflash.css" line: 22 column: 12 source: "	height:100%:"}]

With windowed plugins, this site bug wouldn't caused problems since the native window would overlap a body element with height=0px. With async drawing, we forcing windowless and as a result the plugin also ends up with a height=0px and hence doesn't load.

Hence this is more of a site compat issue.

Comment 27

[Bill Gianopoulos [:WG9s]]

And it took this many months for you to provide this information????n The previous last useful comment was on January 12th.

Comment 28

[Chris Peterson [:cpeterson]]

Karl, can you please help us reach out to the web developer of the youngjump.jp website? They are serving some bad CSS (see comment 26), but only to Firefox. This bad CSS breaks their Flash content in 64-bit Firefox on Win64 and, starting in 54 or 55, will also break on 32-bit Firefox (when we enable Flash async drawing in bug 1340934).

Comment 29

[Karl Dubost💡 :karlcow]

Thanks everyone for the analysis.


In http://youngjump.jp/assets/css/noflash.css

html { 
	height:100%:
}  /* for FF */

body {
	position: relative;
	font: 12px/1.9 '繝偵Λ繧ｮ繝手ｧ偵ざ Pro W3','Hiragino Kaku Gothic Pro','繝｡繧､繝ｪ繧ｪ',Meiryo,'・ｭ・ｳ ・ｰ繧ｴ繧ｷ繝・け','MS PGothic',sans-serif;
}

So the height needs to be fixed. Though I see that it is being reapplied on the element itself.

  <html style="overflow: auto; height: 100%;" lang="ja">
  <!-- cut for brevity -->
  </html>

The site is made by http://www.shueisha.co.jp/
* Please note that all sites are in Japanese only. Unfortunately, we are not able to respond to English inquiries.
The only way to contact them  is by phone it seems. 

Shueisha reader section 03-3230-7755 
Reception hours: 9: 30-12: 00 13: 00-17: 30 (Saturdays, Sundays, holidays holidays) 

They are also on twitter but they do not interact with the public
https://twitter.com/young_jump/with_replies

and all the twitter accounts for their different biz endeavors are not offering a 2 ways communication on twitter
http://www.shueisha.co.jp/pr/twitter.html

東京都千代田区一ツ橋2-5-10　神保町ビル
They are 17 minutes away from the office. :)

Kato-san do you know a better way to contact them than the phone?

Comment 30

[Karl Dubost💡 :karlcow]

forgotten to ni kato-san for the previous comment.

Comment 31

[Makoto Kato [:m_kato]]

Humm, I don't have contact.  But Daisuke-san says, Yoshizawa-san who is W3C/keio might have a contact of Shueisya.

Comment 32

[Karl Dubost💡 :karlcow]

Sent an email to Yoshizawa-san. 
Thanks a lot.

Comment 33

[Karl Dubost💡 :karlcow]

Contacted the Deputy Editor, Young Jump.
(Thanks to Yoshizawa-san).

Comment 34

[Chris Peterson [:cpeterson]]

While youngjump.jp is sending malformed CSS to Firefox, the site will probably work correctly again after we fix 64-bit Firefox bug 1348629 that causes Flash content of size 0x0 pixels to not load.

Comment 35

[Jim Mathies [:jimm]]

(In reply to Chris Peterson [:cpeterson] from comment #34)
> While youngjump.jp is sending malformed CSS to Firefox, the site will
> probably work correctly again after we fix 64-bit Firefox bug 1348629 that
> causes Flash content of size 0x0 pixels to not load.

I don't think this is the case, this bug is present on both 64 and 32 bit builds. bug 1348629 is specific to 64-bit builds and is unrelated to async drawing.

Comment 36

[Julien Cristau [:jcristau] (back April 22)]

Too late for firefox 52, mass-wontfix.

Comment 37

[Liz Henry (:lizzard) (relman/hg->git project)]

Looks like we may have progress here from comment 33. I am dropping this from the platform triage.

Comment 38

[Chris Peterson [:cpeterson]]

http://youngjump.jp/manga/kingdom/ works for me with 64-bit Firefox 53 and Nightly 55. The Flash site shows an empty black page for almost ten seconds in all browsers, so you need to be wait patiently as the site loads.