1290528 - WINDOWPOS y coordinate in Nightly 50.0 is off by one from Release 47.0

Status: RESOLVED WONTFIX

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

Description

[mtalistu]

Attachment: Simple SWF test case. Modify wmode in .html to test variations.

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36

Steps to reproduce:

It appears that Nightly 50.0 is reporting a different value for the WINDOWPOS y coordinate during the WM_WINDOWPOSCHANGED event sent to the Flash Player plugin via NPP_HandleEvent for windowless SWFs.

In 47.0 Release Firefox, the WINDOWPOS y coordinate for the attached test media is 108, but in Nightly 50.0 it is 109.

I tested with Async Drawing disabled and Flash Player's Protected Mode sandbox disabled and saw the same discrepancy, so it doesn't appear to be related to either feature. I am guessing that this may be an injection from the new e10s work?

We use these coordinates to compare the on screen buffer to our internal buffer in some of our security features, such as click-jack protection for the in-SWF Settings UI (right click, select "Settings..." from the context menu). The Settings UI functionality is now broken (Settings UI is unresponsive) due to the rectangles not aligning after this change in y position.


Actual results:

Load "SettingsUITest.html" in Firefox. Right-click on the SWF and select "Settings..." from the context menu. The in-SWF SettingsUI will display. Try to click on any of the tabs or UI controls in the Settings UI (Note that there is an expected 1 second delay in responsiveness, so attempt to click 1 second after the Settings UI is visible). 

The Settings UI is unresponsive in Nightly 50.0 for windowless SWFs, but is responsive in Firefox 47.0 release.

If Async Drawing is not enabled, this will be SWFs with wmode=opaque or transparent. If Async Drawing is enabled, all wmodes will be windowless.


Expected results:

Settings UI should have been responsive for all SWFs.

Comment 1

[mtalistu]

Just for clarification, if Async Drawing is enabled in Nightly, then all wmodes (window/opaque/transparent/direct) are currently treated as windowless with the latest Flash Player beta (23.0)

Comment 2

[Jim Mathies [:jimm]]

Attachment: SettingsUITest.swf

Comment 3

[Jim Mathies [:jimm]]

I haven't been able to reproduce this in any release, e10s on or off using the following flash beta:

    File: NPSWF32_23_0_0_111.dll
    Path: C:\Windows\SysWOW64\Macromed\Flash\NPSWF32_23_0_0_111.dll
    Version: 23.0.0.111
    State: Enabled
    Shockwave Flash 23.0 d0

Comment 4

[Jim Mathies [:jimm]]

Attachment: youtube - windowless.html (transparent)

To use this you have to have 'plugins.rewrite_youtube_embeds' set to false.

Comment 5

[Jim Mathies [:jimm]]

Matt, any idea why there's a difference here? Maybe the different wmodes? (My youtube test case is transparent while yours is opaque.)

Comment 6

[Jim Mathies [:jimm]]

Attachment: youtube - windowless.html (opaque)

The wmode is the difference, not sure why though.

Comment 7

[mtalistu]

I am on a Win 7 Lenovo W520 laptop at the moment. I have tried with both dual monitors and just the laptop display active. With Nightly 51.0.a1 (2016-08-02) and Flash Player 23.0.0.111, I am able to repro.

I have tried wmode=opaque and wmode=transparent with the SettingsUITest.html test case I attached. Transparent may be a more visible test case, since there is a possible graphics glitch in the Settings UI with wmode=opaque in the 23.0.0.11 beta release where text may not display properly (this has since been fixed).

Are you saying that the Settings UI is responsive when you open it? You are able to click on tabs and UI elements, or even just click the "Close" button to dismiss the Settings UI? On my machine, it is completely unresponsive, and the only way to dismiss the Settings UI is to reload the page.

Or are you saying that the Settings UI is unresponsive, but you are not seeing the difference in y coordinate values?

Comment 8

[Jim Mathies [:jimm]]

(In reply to mtalistu from comment #7)
> I am on a Win 7 Lenovo W520 laptop at the moment. I have tried with both
> dual monitors and just the laptop display active. With Nightly 51.0.a1
> (2016-08-02) and Flash Player 23.0.0.111, I am able to repro.
> 
> I have tried wmode=opaque and wmode=transparent with the SettingsUITest.html
> test case I attached. Transparent may be a more visible test case, since
> there is a possible graphics glitch in the Settings UI with wmode=opaque in
> the 23.0.0.11 beta release where text may not display properly (this has
> since been fixed).
> 
> Are you saying that the Settings UI is responsive when you open it? You are
> able to click on tabs and UI elements, or even just click the "Close" button
> to dismiss the Settings UI? On my machine, it is completely unresponsive,
> and the only way to dismiss the Settings UI is to reload the page.
> 
> Or are you saying that the Settings UI is unresponsive, but you are not
> seeing the difference in y coordinate values?

With your settings test case I can reproduce with wmode=opaque, with wmode=transparent I can't. This is using Nightly to test and the beta 23 rev of flash.

My QA gy Tracy Walker is trying to reproduce too, he's not having any luck reproducing using the current release rev of Flash on Win7/Win10 and Nightly. Does this mesh with your expectations?

Comment 9

[mtalistu]

He should be able to reproduce using the latest release rev of Flash Player. Using Flash Player 22.0.0.209 in Nightly 51.0a1, I see the same behavior using my SettingsUITest.html with wmode=transparent as I did with Flash Player 23.0.0.111. 

Using FP 22 in Nightly 51, The in-SWF SettingsUI displays, but is unresponsive to mouse clicks. I cannot click on any tabs/UI elements, and the "Close" button is unresponsive.

If I use the Release Firefox 47.0.1, then the Settings UI is responsive to mouse clicks, etc. with both FP builds (22 and 23)

For my testing, it appears that our in-SWF Settings UI is unresponsive in Nightly 51.0a1 using either FP 22.0.0.209 or FP 23.0.0.111, and this behavior doesn't appear to be dependent on whether Async Drawing is enabled in Firefox (I can repro with "dom.ipc.plugins.asyncdrawing.enabled" set to false) or our Protected Mode sandbox is enabled (I can repro with "ProtectedMode=0" in Flash Player's mms.cfg file, which disables our sandbox)

I am also able to reproduce in both 32-bit and 64-bit Nightly.

Comment 10

[mtalistu]

As an additional data point, if I am using Nightly 51.0a1 (2016-08-02) and I go into "Settings" and uncheck "Enable multi-process Nightly", then the in-SWF Settings UI is responsive again. So, it seems on my machine at least, this behavior is something triggered by the multi-process changes for windowless SWFs.

Comment 11

[Tracy Walker [:tracy]]

I've been using the attachment : youtube - windowless.html (opaque) with 'plugins.rewrite_youtube_embeds' set to false to force use of Flash over html5 video.

Narrowed down the regression range on Windows 7 with Nightly 48.0a1 builds to between 20160405(works) and 20160406(broken).  With broken builds, it doesn't matter if e10s is on or off the SWF Settings dialog is unresponsive in addition to being blurry.

What is puzzling me, at this point, is why this bug is/was not on 48 release/betas.

Comment 12

[Jim Mathies [:jimm]]

(In reply to Tracy Walker [:tracy] from comment #11)
> I've been using the attachment : youtube - windowless.html (opaque) with
> 'plugins.rewrite_youtube_embeds' set to false to force use of Flash over
> html5 video.
> 
> Narrowed down the regression range on Windows 7 with Nightly 48.0a1 builds
> to between 20160405(works) and 20160406(broken).  With broken builds, it
> doesn't matter if e10s is on or off the SWF Settings dialog is unresponsive
> in addition to being blurry.

I can confirm this range. We shoudl sp;ot check +/- a week around this to confirm this sticks.

> What is puzzling me, at this point, is why this bug is/was not on 48
> release/betas.

Was it in 48 aurora builds after the merge from central -> aurora? Does it span that entire cycle up to the 48 merge to beta?

Comment 13

[Tracy Walker [:tracy]]

(In reply to Jim Mathies [:jimm] from comment #12)
> (In reply to Tracy Walker [:tracy] from comment #11)
> > I've been using the attachment : youtube - windowless.html (opaque) with
> > 'plugins.rewrite_youtube_embeds' set to false to force use of Flash over
> > html5 video.
> > 
> > Narrowed down the regression range on Windows 7 with Nightly 48.0a1 builds
> > to between 20160405(works) and 20160406(broken).  With broken builds, it
> > doesn't matter if e10s is on or off the SWF Settings dialog is unresponsive
> > in addition to being blurry.
> 
> I can confirm this range. We shoudl sp;ot check +/- a week around this to
> confirm this sticks.

already confirmed in regression window hunt

> 
> > What is puzzling me, at this point, is why this bug is/was not on 48
> > release/betas.
> 
> Was it in 48 aurora builds after the merge from central -> aurora? Does it
> span that entire cycle up to the 48 merge to beta?

spot checked through the 48 aurora cycle, this bug is there throughout.  The bug is on the last aurora 48 build (20160606) before it merged to 48 beta.  either something was uplifted with the merge or something on release causing this to be fixed there.  This bug is also not affecting the first 49beta even though the bug is present in the 49aurora cycle.  huUUH?

Comment 14

[Jim Mathies [:jimm]]

(In reply to Jim Mathies [:jimm] from comment #12)
> (In reply to Tracy Walker [:tracy] from comment #11)
> > I've been using the attachment : youtube - windowless.html (opaque) with
> > 'plugins.rewrite_youtube_embeds' set to false to force use of Flash over
> > html5 video.
> > 
> > Narrowed down the regression range on Windows 7 with Nightly 48.0a1 builds
> > to between 20160405(works) and 20160406(broken).  With broken builds, it
> > doesn't matter if e10s is on or off the SWF Settings dialog is unresponsive
> > in addition to being blurry.
> 
> I can confirm this range.

changesets in here:

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d9f50aa0a1aaf90499b85c31e0f329b762e80fdd&tochange=68c0b7d6f16ce5bb023e08050102b5f2fe4aacd8

Comment 15

[Jim Mathies [:jimm]]

apparently this only impacts dev builds.

Comment 16

[Matt Wobensmith [:mwobensmith][:matt:]]

Removing security flag, as this is not exposing any security issues for users. It's a graphics issue that results in a loss of feature functionality for Flash Player users.

Comment 17

[Chris Peterson [:cpeterson]]

Is the bug reproducible with e10s disabled? That might explain why Aurora 48 was affected but not Beta 48. e10s has been enabled by default in Nightly and Aurora channels for a long time, but not in Beta. We began enabling e10s for a small number of users during Beta 48 and for all (eligible) users in Beta 49.

To disable e10s, uncheck "Enable multi-process Firefox" in about:preferences.

Comment 18

[Tracy Walker [:tracy]]

Like I said previously:

(In reply to Tracy Walker [:tracy] from comment #11)
> With broken builds, it doesn't matter if e10s is on or off, 
> the SWF Settings dialog is unresponsive in addition to being blurry.

Comment 19

[Benjamin Smedberg]

I'm confused by the state of this bug.

There are four attachments to this bug. #1 is by mtalistu. #2-4 are from jmathies. Testcase #3-4 only work if plugins.rewrite_youtube_embeds is disabled.

Here's my current understanding:
This issue affected Firefox 48 aurora, but not the equivalent Firefox 48 beta.
This issue affected Firefox 49 aurora, but not the equivalent Firefox 49 beta.
For Tracy, there's a regression in nightly between 48.0a1 between 20160405(works) and 20160406(broken) in both e10s and non-e10s configs. What testcase was used to determine this?
For mtalistu running Nightly 51.0a1 (2016-08-02), the issue only reproduces with e10s on. Is that with testcase #1?

I tried testcase #1 in currently nightly x86-64 with e10s and couldn't reproduce any problems. Is that expected, according to everyone's current understanding of the bug?

I have the following theories about this bug:

The difference between aurora and beta makes me think Flash is making some decision based on the branding, useragent, or buildid of official branded Firefox versus prerelease. Matt, is this likely?

The one-pixel difference, and variable reproducibility, feels like the kind of issue that might be caused by subpixel coordinate systems and/or high-DPI screen hijinks. Tracy/Jim/Matt, which of you are using high-DPI screens?

Adobe has asked us to look at this urgently so we can verify the async-drawing rollout. Do we have enough evidence to be confident that this shouldn't affect async-drawing rollout for our beta/release population?

Comment 20

[mtalistu]

All my testing was only done with testcase #1. I have not done any testing with the other test cases.

I don't think that the difference is based on any decision that Flash Player is making. As I said, the difference that I see is in the WINDOWPOS y coordinate from the WM_WINDOWPOSCHANGED event sent to the Flash Player plugin via NPP_HandleEvent for windowless SWFs.

With e10s enabled, this Y coordinate is one larger than without. (i.e. 109 with e10s, 108 without e10s) As far as I understand it, this Y coordinate comes from the browser. If leave e10s on, and then I modify this value in the debugger and change it back to 108, then our Settings UI is responsive.

I'm using the recommended 1920x1080 resolution on my Lenovo w520 laptop, with text size set to the default "Medium" value of 125%. If I changed the text size to "Smaller" (100%), then the issue is fixed. With e10s enabled, the Settings UI is responsive again.

So, it seems that high-DPI is the culprit. Not sure why this would only affect Nightly x86 on my machine, and not the other two browser versions.

Comment 21

[mtalistu]

Sorry, scratch the comment about it only affecting Nightly x86... I was getting confused between this and the other bug. This Settings UI failure happens for me in both Nightly x86 and Nightly x64 with e10s enabled and high-DPI (text size set to 125%). 

Also note: If I disable e10s, but leave text size set to 125%, the Settings UI works as expected in both browsers.

Comment 22

[Tracy Walker [:tracy]]

I began to recheck my testing (using  youtube - windowless.html (opaque), same as before). To my dismay, I am not getting the same results I did two weeks ago.  Currently I am unable to reproduce the bug on builds around the reported regression that previously had failed. Also latest Nightly is not failing, as hit had before.  Investigating...

Comment 23

[Tracy Walker [:tracy]]

Extremely odd, I can not reproduce this with latest Nightly 51.0a1, 20160815030201.  I've tried with e10s on and with e10s off.   I've tried with system text size at 100%  (my system default) and at 125%.  I've tried on my Retina MBP display and my external monitor (see hardware data below). I've tied with combinations of all the above.  Again I am using attached testcase youtube - windowless.html (opaque, as that is what I was able to reproduce this bug with initially). Shockwave Flash 23.0.0.134 plugin with 'plugins.rewrite_youtube_embeds' set to false to force use of Flash over html5 video.

Sorry I didn't make note of which version of the flash player I was using on 8/2. I do recall digging up the 23 beta; 23.0.0.something. (what would have been available for download on 8/2?) That is the only thing that I can tell that might be different than the configuration I am using now.

AMD Radeon R9 M370X:

  Chipset Model:	AMD Radeon R9 M370X
  Type:	GPU
  Bus:	PCIe
  PCIe Lane Width:	x8
  VRAM (Total):	2048 MB
  Vendor:	ATI (0x1002)
  Device ID:	0x6821
  Revision ID:	0x0083
  ROM Revision:	113-C5670E-777
  gMux Version:	4.0.20 [3.2.8]
  EFI Driver Version:	01.00.777
  Displays:
Color LCD:
  Display Type:	Retina LCD
  Resolution:	2880 x 1800 Retina
  Retina:	Yes
  Pixel Depth:	32-Bit Color (ARGB8888)
  Mirror:	Off
  Online:	Yes
  Built-In:	Yes
HP 25xi:
  Resolution:	1920 x 1080 @ 60Hz (1080p)
  Pixel Depth:	32-Bit Color (ARGB8888)
  Display Serial Number:	3CM31103BM  
  Main Display:	Yes
  Mirror:	Off
  Online:	Yes
  Rotation:	Supported
  Television:	Yes

Comment 24

[Tracy Walker [:tracy]]

My theory that FP 23 fixed it is not upheld.  The bug is also works for me with latest Nightly using release FP 22.0.0.209

Comment 25

[Jim Mathies [:jimm]]

Can you go back and spot check the nightly builds we were using originally? I'd like to know if this was something we fixed on our end.

I just tested nightly with the adobe test case, wmode=opaque, on a laptop running at 200% resolution and I can't reproduce.

Comment 26

[Tracy Walker [:tracy]]

I am baffled.  Nightly builds from 20160406 and 20160415 which were broken before are working now.

Comment 27

[Jim Mathies [:jimm]]

This bug isn't tied to async drawing.

Comment 28

[Jim Mathies [:jimm]]

Tried to repo, this time by setting my dpi scaling to 125% (windows 7 64-bit, 32-bit nightly). Still not able to repo.

Comment 29

[BMO Automation]

Resolving as wont fix, plugin support deprecated in Firefox 85.