866365 - Mouse input behavior acts oddly in windowless flash on hidpi systems

Status: RESOLVED WORKSFORME

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

Description

[Greg Edwards]

Set Windows's DPI to something high. (I'm using 192)
Navigate to http://www.animusic.com/
Move the mouse over the Reviews and Support items. Notice that they won't expand.
Now nagivate to a subpage. (like http://www.animusic.com/news/index.php )
Notice the navigation being tiny and out-of-place. (This is Bug 820831.)
Now hover your mouse over these small menu items.
Notice the graphics corruption in the background. This seems to be related to poor handling of transparency.

Bug 820831 is a problem with Flash and affects IE as well, but it's a BAD bug on HiDPI configurations. I haven't heard a peep out of Adobe with regards to fixing it. The other two bugs here don't affect IE.

Comment 1

[Greg Edwards]

The mouse-related issues only happen with hiDPI enabled so count as a regresion of Bug 844604.

Comment 2

[Georg Fritzsche [:gfritzsche]]

Per bug 820831 Flash doesn't handle HiDPI properly, so i'm not sure if we can fix this.

Comment 3

[Greg Edwards]

As I said in comment #0, the mouse and transparency issues don't affect IE so they are on our end.

Comment 4

[Benjamin Smedberg]

Is this windowed or windowless Flash?

Comment 5

[Greg Edwards]

Benjamin: I don't quite understand. Do you mean fullscreen vs. windowed Flash applets? Or the same for Firefox? I am running everything windowed. I'm not the website author but I don't believe anything special is being done to embed the Flash.

In other news, I just found a workaround that seems to solve both issues:
1. Navigate to the Firefox folder. (C:\Program Files (x86)\Nightly in my case)
2. Right click plugin-container.exe and choose Properites.
3. Under the Compatability tab, check "Disable display scaling on high DPI settings"
4. Restart Firefox.

(Bug 820831 still happens, of course)

This means fixing the issue should only be a matter of adding the DPI-aware flag to plugin-container.exe's manifest.

Comment 6

[Greg Edwards]

Correction, I can still replicate the alpha issue but mouse handling appears fixed.

Comment 7

[Georg Fritzsche [:gfritzsche]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> Is this windowed or windowless Flash?

Windowless, they are using |<param name="wmode" value="transparent">|.

jimm, do you know if making the plugin-container makes sense here or could that have undesired side-effects?

Comment 8

[Greg Edwards]

wmode=transparent is being used on that site.

Comment 9

[Jim Mathies [:jimm]]

(In reply to Georg Fritzsche [:gfritzsche] from comment #7)
> (In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> > Is this windowed or windowless Flash?
> 
> Windowless, they are using |<param name="wmode" value="transparent">|.
> 
> jimm, do you know if making the plugin-container makes sense here or could
> that have undesired side-effects?

Not sure what you are asking. "making the plugin-container"?

Curious, what are the remaining issues here? According to comment 6 everything except an "alpha issue" has been addressed. Can we update the bug reflecting the current state of things and if this is a rendering related issue attach a screen cap of the problem?

Comment 10

[Greg Edwards]

Attachment: Graphics errors on Flash menu with transparency

There are three issues:
1. Bug 820831
2. Mouse hover behaviour is broken. I can fix by tweaking Windows compatability settings
3. Graphics errors when interacting with some Flash applets. A screenshot is attached. (This corruption is flashed for the occasional single frame when I jiggle the mouse up and down.)

Comment 11

[Alex Keybl [:akeybl]]

Who wants this? Or do we suspect this is a corner case specific to the cited website?

Comment 12

[Georg Fritzsche [:gfritzsche]]

(In reply to Jim Mathies [:jimm] from comment #9)
> Not sure what you are asking. "making the plugin-container"?

Sorry, i lost a part there: "making the plugin-container dpi-aware" per comment 5.

(In reply to Alex Keybl [:akeybl] from comment #11)
> Who wants this? Or do we suspect this is a corner case specific to the cited
> website?

I suspect this could affect mouse handling of more Flash instances on HiDPI settings on Windows. Not sure though i don't have used such a setup yet myself, jfkthame might know?

Comment 13

[Greg Edwards]

I run into mouse handling issues and Bug 820831 almost everywhere that uses Flash.
Stumbling into the graphics errors was dumb luck on my part when testing replication of the mouse issues.

Comment 14

[Jonathan Kew [:jfkthame]]

I can see flash-scaling problems on the animusic.com site with Windows DPI set to 144 or 192 (for example) - the home page looks fine, but the Flash header on subsidiary pages such as Reviews and News is scaled wrong, and flickers oddly when moused-over. I'm not sure why this is; I haven't seen similar issues with Flash on other sites such as youtube.

Note than on OS X/Retina, the Flash header on animusic.com pages also behaves a bit oddly, with a strange flicker when the mouse passes over it, although the basic display is correctly scaled. Still, it seems like there may be something unusual about how they're deploying this.

I'll try to experiment with manifest changes as suggested, and see if that affects the behavior I'm seeing.

At this point, I'm not sure this is a widespread problem; it looks to me like it may be some kind of "corner case" related to exactly how animusic.com is using Flash. If there are other sites that show similar issues, please let us know.

Comment 15

[Greg Edwards]

I see bad scaling on Youtube and other Flash-based video sites. (Make sure the video you're viewing isn't HTML5)

I can replicate the mouse issues on ABSOLUTELY ANY page using Flash, eg. http://www.speedtest.net/
This is the only issue a manifest would fix.

The graphics errors are probably an edge case, mouse issues are bad and should be fixed, scaling will require some evangelism at Adobe.

Comment 16

[Jim Mathies [:jimm]]

Ok, I'm able to reproduce on a youtube video.

Comment 17

[Jim Mathies [:jimm]]

Attachment: youtube windowless

Comment 18

[Jonathan Kew [:jfkthame]]

(In reply to Greg Edwards from comment #15)
> I see bad scaling on Youtube and other Flash-based video sites. (Make sure
> the video you're viewing isn't HTML5)

By "bad scaling" do you mean controls that are smaller than expected, or that the entire Flash object is mis-scaled? I do see miniature controls, though they still appear to work fine.

> 
> I can replicate the mouse issues on ABSOLUTELY ANY page using Flash, eg.
> http://www.speedtest.net/
> This is the only issue a manifest would fix.

Not seeing that here. speedtest.net looks and behaves OK for me.

One mouse-related issue that I do see everywhere is that the right-click context menu pops up in the wrong place - looks like it's twice as far to the right/down as it should be (with Windows set to 192dpi). But it sounds to me like you're describing more extensive problems than that.

Comment 19

[Greg Edwards]

Mouse hover transitions are broken for me on speedtest.net. The buttons flicker between their hovered and unhovered colours when my mouse is over them, and the settle on the unhovered colour (green) when the mouse isn't moving.

Comment 20

[Jim Mathies [:jimm]]

> One mouse-related issue that I do see everywhere is that the right-click
> context menu pops up in the wrong place - looks like it's twice as far to
> the right/down as it should be (with Windows set to 192dpi). But it sounds
> to me like you're describing more extensive problems than that.

I see that as well in my test case. The menu is also fuzzy, which implies Windows is doing dpi virtualization.

http://msdn.microsoft.com/en-us/library/windows/desktop/dd464660(v=vs.85).aspx

One other oddity, in the youtube video only the controls on the left act weird, the buttons / flyouts on the right are fine.

Comment 21

[Jonathan Kew [:jfkthame]]

I've been experimenting with adding the dpiAware flag to the manifest in plugin-container.exe. AFAICT from my testing, this fixes the problem with the right-click menu on the Flash plugin - it now appears in the correct place, and without blurriness - but it does NOT appear to help with the mouse issues (erratic hover effects, etc) within the Flash object itself.

I DO see an improvement there if I use the Properties dialog to "Disable display scaling" for plugin-container.exe. So it appears that setting the flag in the manifest does not achieve as manually setting the Properties flag does. That's sad. :(

I've pushed a tryserver build (https://tbpl.mozilla.org/?tree=Try&rev=1809543e9cdd) with the plugin-container manifest change, so others can test this and see what effect it has.

Comment 22

[Jonathan Kew [:jfkthame]]

(In reply to Jonathan Kew (:jfkthame) from comment #21)
> So it appears that setting the
> flag in the manifest does not achieve as manually setting the Properties
> flag does. That's sad. :(

That was of course meant to say "...achieve the same effect as..."

Comment 23

[Greg Edwards]

Not so fast! By disabling DPI virtualization on FlashPlayerPlugin_11_7_700_169.exe, I can also fix mouse behaviour.

Maybe the properties page disables it for the entire process tree, but the manifest just disables it for the specific process?

Upd: I also checked that box for firefox.exe and it fixes BOTH the menu and mouse behaviour, supporting my suspicion.

Comment 24

[Jim Mathies [:jimm]]

(In reply to Greg Edwards from comment #23)
> Not so fast! By disabling DPI virtualization on
> FlashPlayerPlugin_11_7_700_169.exe, I can also fix mouse behaviour.
> 
> Maybe the properties page disables it for the entire process tree, but the
> manifest just disables it for the specific process?
> 
> Upd: I also checked that box for firefox.exe and it fixes BOTH the menu and
> mouse behaviour, supporting my suspicion.

A couple pointers - we call SetProcessDPIAware on init - 

http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#2855

We could try adding this to the child process init. Although it sounds like flash's exe maybe be part of the problem.

Comment 25

[Jonathan Kew [:jfkthame]]

(In reply to Jim Mathies [:jimm] from comment #24)
> (In reply to Greg Edwards from comment #23)
> > Not so fast! By disabling DPI virtualization on
> > FlashPlayerPlugin_11_7_700_169.exe, I can also fix mouse behaviour.
> > 
> > Maybe the properties page disables it for the entire process tree, but the
> > manifest just disables it for the specific process?
> > 
> > Upd: I also checked that box for firefox.exe and it fixes BOTH the menu and
> > mouse behaviour, supporting my suspicion.
> 
> A couple pointers - we call SetProcessDPIAware on init - 
> 
> http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.
> cpp#2855
> 
> We could try adding this to the child process init. Although it sounds like
> flash's exe maybe be part of the problem.

My understanding from the docs on MSDN is that this is equivalent to declaring the process as dpiAware via the manifest (which is the preferred approach). But we can certainly give it a try and see if there's any observable difference.

Comment 26

[Jonathan Kew [:jfkthame]]

(In reply to Jonathan Kew (:jfkthame) from comment #25)
> (In reply to Jim Mathies [:jimm] from comment #24)
> > A couple pointers - we call SetProcessDPIAware on init - 
> > 
> > http://mxr.mozilla.org/mozilla-central/source/toolkit/xre/nsAppRunner.
> > cpp#2855
> > 
> > We could try adding this to the child process init. Although it sounds like
> > flash's exe maybe be part of the problem.
> 
> My understanding from the docs on MSDN is that this is equivalent to
> declaring the process as dpiAware via the manifest (which is the preferred
> approach). But we can certainly give it a try and see if there's any
> observable difference.

AFAICT, there's no difference between the behavior after calling SetProcessDPIAware and the result of setting dpiAware in the manifest.

Maybe it'd make sense to simply move the call to SetProcessDPIAware from nsAppRunner.cpp (where it gets used by firefox.exe, but not by plugin-container.exe) over to the wmain() function in nsWindowsWMain.cpp. That way it'll be part of plugin-container.exe as well. I've pushed a tryserver build with this change, to check it doesn't break anything major... https://tbpl.mozilla.org/?tree=Try&rev=4a00018771f4

What I don't yet understand is why disabling dpi-scaling via the .exe's Properties panel seems to have an effect that's "inherited" by child processes (as described by Greg above), while using SetProcessDPIAware and/or the manifest affects -only- the current process. I haven't found any info on MSDN or elsewhere about this... any pointers would be welcome.

Comment 27

[Jim Mathies [:jimm]]

I did some searching and didn't find much either. If we need to we can get adobe involved and have them set dpi aware on their exe as well. The only browser that uses their low integrity sub process model is firefox afaik.

Comment 28

[Jonathan Kew [:jfkthame]]

OK... it appears that how the Properties checkbox works is by setting a registry value at HKCU\Software\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers\<full-path-of-the-executable> with the data HIGHDPIAWARE. If I create this registry entry for my Nightly build, it "fixes" the mouse issues in the Flash examples.

Still no idea -why- this setting is apparently propagated to the child process(es), while dpi-awareness set programmatically or via the manifest is not, but in principle I suppose we could make the Firefox installer/updater set this. It can be set either for the current user only (under HKCU) or for all users on the machine (HKLM).

Comment 29

[Jonathan Kew [:jfkthame]]

FWIW, I tried using Microsoft's manifest tool to add the <dpiAware> setting to the manifest in FlashPlayerPlugin_11_7_700_169.exe, but this does *not* appear to help with the mouse-hover issues in the same way that setting the Disable Scaling option in the Properties panel does.

Comment 30

[Jonathan Kew [:jfkthame]]

Hmm, maybe I did something wrong in comment 29; after further testing, I've come to the conclusion that we should ask Adobe to declare FlashPlayerPlugin as dpi-aware in its manifest. With this, the mouse-hover issues seem to be fixed for all the various settings I've tested.

We also need to declare plugin-container.exe to be dpi-aware, in order to make the right-click context menu work properly, as already noted. We can either do this by calling SetProcessDPIAware as early as possible during startup (like we currently do in firefox.exe), or we can do it by adding the <dpiAware> entry to the executable's manifest.

According to MSDN[1], using the manifest is the recommended approach, with the SetProcessDPIAware API being "discouraged, except in very specific circumstances". As such, I propose that we use the manifest both for firefox itself and for plugin-container; I'll post a patch that does this.

A tryserver build with this patch is at https://tbpl.mozilla.org/?tree=Try&rev=e8b1f87fcfd9. With this build, the right-click context menu for Flash objects should be fixed (appears at the correct place, and no longer blurry).

To fix the mouse-hover issues within Flash, it's necessary to use Microsoft's manifest tool (mt.exe) to add the dpi-awareness fragment to the plugin .exe's manifest. To do this, for testing purposes:

(0) ensure mt.exe is available (e.g. as part of a Visual Studio install)

(1) copy FlashPlayerPlugin_11_7_700_169.exe from c:\windows\syswow64\macromed\flash\ (or wherever...) to a temporary, writable directory for modification

(1a) unless you're supremely confident, save a copy of this file just in case you later want to restore it to its original state

(2) download the dpi-aware.manifest file that I'll attach here to the same directory

(3) run the two commands

  mt "-inputresource:FlashPlayerPlugin_11_7_700_169.exe;#1" -out:flash-orig.manifest

  mt -manifest flash-orig.manifest dpi-aware.manifest "-outputresource:FlashPlayerPlugin_11_7_700_169.exe;#1"

(MT should print its version number each time, but no warning/error messages.)

(4) copy the modified plugin back to the system directory, replacing the original (admin authorisation will be needed; may also need to quit any browser that's currently using it)

With the tryserver build mentioned above, and this modified copy of the Flash plugin, the erratic mouse-hover interactions, etc., should be fixed.

The remaining issue is that the Flash video controls, etc., remain unscaled (i.e. very small) on hi-dpi systems, although they work correctly. I'll follow up about that separately.

[1] http://msdn.microsoft.com/en-us/library/windows/desktop/dd464660%28v=vs.85%29.aspx#declaring_dpi_awareness

Comment 31

[Jonathan Kew [:jfkthame]]

Attachment: dpi-aware.manifest, for merging into the Flash plugin .exe

This is the manifest addition needed for the Flash plugin. It can be merged with the plugin's existing manifest using MT.exe, as described above.

Comment 32

[Jonathan Kew [:jfkthame]]

Attachment: patch, declare both firefox.exe and plugin-container.exe as dpi-aware via their manifests

This fixes the popup (context) menu for the plugin. It does not fix the mouse-interaction/hover issues within the plugin; that requires modifying the manifest in the actual plugin .exe, as described above.

Comment 33

[Jonathan Kew [:jfkthame]]

Jet (or anyone with appropriate contacts at Adobe), can we persuade the Flash team to add the dpiAware manifest fragment to the plugin .exe, as described above? AFAICT, that's the only reliable way to get the bug here fixed, so that mouse interaction works consistently.

Comment 34

[Jim Mathies [:jimm]]

Comment on attachment 745669 [details] [diff] [review]
patch, declare both firefox.exe and plugin-container.exe as dpi-aware via their manifests

Review of attachment 745669 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/app/Makefile.in
@@ +86,5 @@
>  WIN32_EXE_LDFLAGS += -ENTRY:wmainCRTStartup
>  endif
>  
>  ifeq ($(OS_ARCH),WINNT)
> +EXTRA_DEPS += $(PROGRAM).manifest

The manifest is already included through splash.rc, not sure we need this.

Comment 35

[Jonathan Kew [:jfkthame]]

> >  ifeq ($(OS_ARCH),WINNT)
> > +EXTRA_DEPS += $(PROGRAM).manifest
> 
> The manifest is already included through splash.rc, not sure we need this.

It's included, yes, but the dependency is not known to Make, and so modifying the manifest file does not cause the .exe to be updated. That's why I added this - but I'd like a build-system person to confirm whether it's a reasonable fix, or if there's an alternative they'd prefer.

Comment 36

[Jonathan Kew [:jfkthame]]

Comment on attachment 745669 [details] [diff] [review]
patch, declare both firefox.exe and plugin-container.exe as dpi-aware via their manifests

:gps, are you ok with the use of EXTRA_DEPS in the Makefile.in changes here, or is there a better way to do this?

Comment 37

[Gregory Szorc [:gps]]

Comment on attachment 745669 [details] [diff] [review]
patch, declare both firefox.exe and plugin-container.exe as dpi-aware via their manifests

Review of attachment 745669 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/app/Makefile.in
@@ +86,5 @@
>  WIN32_EXE_LDFLAGS += -ENTRY:wmainCRTStartup
>  endif
>  
>  ifeq ($(OS_ARCH),WINNT)
> +EXTRA_DEPS += $(PROGRAM).manifest

Adding firefox.exe.manifest to the global dependency list to force rebuilds of everything if it changes seems at least partially correct. It's not fully correct because there are things in this Makefile.in that don't depend on the manifest.

But, the manifest file should change rarely, so I'm willing to let it slide because I /think/ doing it right requires more work than it is worth. Please add a comment documenting it should really only apply to specific targets (I assume the output .exe in one?).

Comment 38

[Jeromie Clark]

This is Adobe 3555161

Comment 39

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/081ebf4e0886

This won't actually resolve all the issues here, as we also need the corresponding fix to the Flash plugin; leaving this open for now to keep it on our radar.

Comment 40

[Jonathan Kew [:jfkthame]]

Hmm, I saw a comment go by from NeilAway (on irc) pointing out that this may affect other applications that were relying on SetProcessDPIAware being called for them from XRE_mainInit().

Arguably, the right thing for other apps to do (just like Firefox) would be to declare themselves dpi-aware via their manifest; this is the MS recommended approach. However, if this is going to be excessively burdensome or disruptive, maybe we should consider reverting the change in nsAppRunner.cpp here. We could still leave the dpiAware element in the firefox.exe manifest as well; the SetProcessDPIAware call would be redundant but harmless.

Comment 41

[Jim Mathies [:jimm]]

Maybe just relnote / devdoc this so xulrunner apps know about it?

Comment 42

[Jim Mathies [:jimm]]

I guess we would also need to file a couple bugs for thunderbird and seamonkey.

Comment 43

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/081ebf4e0886

Comment 44

[Jonathan Kew [:jfkthame]]

(In reply to Jeromie Clark from comment #38)
> This is Adobe 3555161

Thanks, Jeromie. Is this something we can track, to monitor progress, or is it Adobe-internal only? I tried https://bugbase.adobe.com/index.cfm?event=bug&id=3555161, but that doesn't return anything - wrong tracker, maybe?

In particular, can you tell us anything about the likely timescale for a fix to be deployed (even the minimal fix of just adding dpiAware to the manifest)? It'd be highly desirable for this to be available by the time Firefox 22 ships, otherwise users are going to experience the erratic behavior described here.

Comment 45

[Jonathan Kew [:jfkthame]]

(In reply to Jim Mathies [:jimm] from comment #42)
> I guess we would also need to file a couple bugs for thunderbird and
> seamonkey.

Filed bug 869890 (thunderbird) and bug 869891 (seamonkey).

Comment 46

[Jonathan Kew [:jfkthame]]

Comment on attachment 745669 [details] [diff] [review]
patch, declare both firefox.exe and plugin-container.exe as dpi-aware via their manifests

[Approval Request Comment]
Bug caused by (feature/regressing bug #): hidpi support

User impact if declined: right-click (context) menu for plugins is misplaced and blurry

Testing completed (on m-c, etc.): tested locally, landed on m-c

Risk to taking this patch (and alternatives if risky): low risk - sets dpi-awareness on plugin-container.exe, which we should probably always have done, but would have had no visible effect in non-hidpi configurations

String or IDL/UUID changes made by this patch: none


(Note that by itself this patch does not fully resolve the mouse-interaction issues described in this bug; we also need Adobe to make the corresponding fix to the Flash plugin itself.)

Comment 47

[Greg Edwards]

(In reply to Jonathan Kew (:jfkthame) from comment #44)
> In particular, can you tell us anything about the likely timescale for a fix
> to be deployed (even the minimal fix of just adding dpiAware to the
> manifest)? It'd be highly desirable for this to be available by the time
> Firefox 22 ships, otherwise users are going to experience the erratic
> behavior described here.
Just to let you know, the erratic mouse behaviour (and graphics errors on the animusic site) affect ALL versions of Firefox, even before bug 844604 lands. The only necessary trigger is putting Windows into a high enough DPI (150%+) to enable virtualization.

This means time is of the essence in getting a fix out of Adobe, and that backing out 844604 won't help anything.

Also if you have some insider contact with Adobe, can you please remind them that Flash applets need to be scaled to the browser zoom? (Bug 820831 / https://bugbase.adobe.com/index.cfm?event=bug&id=3536168 )

Comment 48

[Alex Keybl [:akeybl]]

(In reply to Jonathan Kew (:jfkthame) from comment #46)
> (Note that by itself this patch does not fully resolve the mouse-interaction
> issues described in this bug; we also need Adobe to make the corresponding
> fix to the Flash plugin itself.)

Noted - does anybody in this bug think the full resolution of this bug should block the feature entirely in FF22?

(In reply to Greg Edwards from comment #47)
> This means time is of the essence in getting a fix out of Adobe, and that
> backing out 844604 won't help anything.

Is this true? If so, what would it take to have a solution that only requires changes on our end?

Comment 49

[Benjamin Smedberg]

Is this a new regression/feature in FF22? We probably have the capacity to inject a call to SetProcessDPIAware into the FlashPlayer process, if we're desperate. I figured this was just a longstanding issue and there was no urgency.

Comment 50

[Greg Edwards]

It shouldn't block the feature in Firefox 22 since it happens anyway and is unrelated to that stuff. (I'll remove the bug 844604 block since this ISN'T a regression of that.)

The only Firefox-only solution I can think of is the bad registry hack discussed in Comment 28. (Applying the hack to plugin-container.exe would probably be the least painful place to do it since it's our executable and not someone else's.)

Comment 51

[Greg Edwards]

Ben: Correct. This is an old issue that went unnoticed because there weren't many high density screens until recently so no one encountered Windows DPI virtualization.

Comment 52

[Jeromie Clark]

@Jonathan - the externally visible bug wouldn't be updated until the change was released, which wouldn't add any value for you.  

I'm circulating the issue internally to get some traction on it.  If this is a mission-critical imperative for Mozilla, I'd recommend escalating through the official channel as well.  It will make it easier for me to get resources on it.  

In general, the timeframe for when the change would land is primarily dependent on whether or not this is actually as simple as a manifest change, and what the actual level of risk (security and stability in the context of our existing planned work and release schedule) is.  

To add some context, enabling Retina support was a non-trivial effort.

Once a developer is assigned and has the time to do some discovery, we would be in a position to have a meaningful conversation about time-frame, etc.

I'll pass 820831/3536168 along to the engineering team as well.  I don't think the team triaging the public bugbase realized it was a request from Mozilla, and probably didn't know what to do about the high-dpi requirement (they wouldn't have immediate, easy access to the required gear).

As always, Mozilla folks should definitely feel free to ping me directly if you're not getting traction on bugs.  I'll do my best to get attention on them.

Comment 53

[Jonathan Kew [:jfkthame]]

(In reply to Jeromie Clark from comment #52)
> In general, the timeframe for when the change would land is primarily
> dependent on whether or not this is actually as simple as a manifest change,
> and what the actual level of risk (security and stability in the context of
> our existing planned work and release schedule) is.  

AFAICT, the manifest change in flashplayer.exe is sufficient to fix the erratic mouse interaction issues described here. (Obviously, I'd expect you'll want to test it thoroughly, though, rather than just assume I'm right!)

There's also the separate issue of the scaling of controls in flash movies, so that they remain constant size as pixel density increases. (Currently, on a 192dpi Windows machine, you get half-size video controls in flash.) I think this aspect will require additional changes on both the mozilla and adobe sides; I've begun some investigation and will file a separate bug on that aspect.

Comment 54

[Greg Edwards]

Jonathan: That bug is already filed by me as Bug 820831, and with Adobe at https://bugbase.adobe.com/index.cfm?event=bug&id=3536168 . I tell them to use IE since it supported hiDPI since version 8.

Comment 55

[Masatoshi Kimura [:emk]]

(In reply to Jonathan Kew (:jfkthame) from comment #26)
> What I don't yet understand is why disabling dpi-scaling via the .exe's
> Properties panel seems to have an effect that's "inherited" by child
> processes (as described by Greg above), while using SetProcessDPIAware
> and/or the manifest affects -only- the current process. I haven't found any
> info on MSDN or elsewhere about this... any pointers would be welcome.

Applied compatibility shims are stored in an environment variable:

  __COMPAT_LAYER=HighDpiAware

It will be inherited because it is an environment variable. We can even define this environment variable manually to disable dpi-scaling of descendant processes without modification of the registry or the manifest.

Comment 56

[Jonathan Kew [:jfkthame]]

(In reply to Masatoshi Kimura [:emk] from comment #55)
> (In reply to Jonathan Kew (:jfkthame) from comment #26)
> > What I don't yet understand is why disabling dpi-scaling via the .exe's
> > Properties panel seems to have an effect that's "inherited" by child
> > processes (as described by Greg above), while using SetProcessDPIAware
> > and/or the manifest affects -only- the current process. I haven't found any
> > info on MSDN or elsewhere about this... any pointers would be welcome.
> 
> Applied compatibility shims are stored in an environment variable:
> 
>   __COMPAT_LAYER=HighDpiAware
> 
> It will be inherited because it is an environment variable. We can even
> define this environment variable manually to disable dpi-scaling of
> descendant processes without modification of the registry or the manifest.

That's interesting, and sounds like it ought to be a possible workaround. However, I've just been trying this - setting this variable (tried using both libc's putenv() and the Win32 API SetEnvironmentVariable) in the firefox and/or the plugin-container processes, expecting it to be inherited by the plugin - but it doesn't seem to have any effect on the mouse-hover problems in Flash.

(Does the Flash .dll deliberately launch the Flash .exe in a clean "sandboxed" environment that does not inherit any env vars from the firefox or plugin-container process?)

Comment 57

[Greg Edwards]

Works for me from a cmd shell:

set __COMPAT_LAYER=HighDpiAware
cd "C:\Program Files (x86)\Nightly"
firefox

Flash works properly in the Firefox instance it opens.

Comment 58

[Jonathan Kew [:jfkthame]]

What Windows dpi setting are you running at?

Comment 59

[Greg Edwards]

192, but I just tested at all the other scales. It works the same for me on 144 and on 120 if I uncheck the "XP style" setting. So in other words, whenever DPI virtualization is enabled.

Comment 60

[Masatoshi Kimura [:emk]]

Yeah, I tried it from the command shell and it worked. I don't understand why it doesn't work when using the API directly.

Comment 61

[Jonathan Kew [:jfkthame]]

Were you testing on Win7 or Win8?

On Win7, I can reproduce the "fix" by running with the __COMPAT_LAYER setting from the command shell, but on Win8 it doesn't seem to work for me. (I was on Win8 when trying to set the env var from within the firefox process. So I don't know whether that might actually have worked on Win7.)

Comment 62

[Alex Keybl [:akeybl]]

Benjamin - comment 51 doesn't make it less of an issue does it? This occurred previously, yes, but not with the same severity.

Comment 63

[[e-mail]]

Comment on attachment 745669 [details] [diff] [review]
patch, declare both firefox.exe and plugin-container.exe as dpi-aware via their manifests

>+  <ms_asmv3:application xmlns:ms_asmv3="urn:schemas-microsoft-com:asm.v3">
>+    <ms_asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
>+      <dpiAware>true</dpiAware>
>+    </ms_asmv3:windowsSettings>
>+  </ms_asmv3:application>
Weird; for some reason my version of mt.exe (5.2.3790.2076) doesn't like the xmlns on the parent (just exits with code 31 without a diagnostic) but works fine when I move it to the dpiAware element.

Comment 64

[Greg Edwards]

(In reply to Jonathan Kew (:jfkthame) from comment #61)
> Were you testing on Win7 or Win8?

Seven. Maybe the envar is named differently on 8 or some other breaking change? Does the reg hack/property pane fix work the same way on 8?

Comment 65

[Masatoshi Kimura [:emk]]

(In reply to Jonathan Kew (:jfkthame) from comment #61)
> Were you testing on Win7 or Win8?

On Win8, I was unable to reproduce the "mouse-hover issue" even without any compatibility settings.
Could you instruct me a more detailed step-by-step STR, an expected result, and an actual result?

Comment 66

[Jonathan Kew [:jfkthame]]

https://hg.mozilla.org/releases/mozilla-aurora/rev/46f7b0359f15

Comment 67

[Jonathan Kew [:jfkthame]]

(In reply to Masatoshi Kimura [:emk] from comment #65)
> (In reply to Jonathan Kew (:jfkthame) from comment #61)
> > Were you testing on Win7 or Win8?
> 
> On Win8, I was unable to reproduce the "mouse-hover issue" even without any
> compatibility settings.
> Could you instruct me a more detailed step-by-step STR, an expected result,
> and an actual result?

Here's what consistently reproduces the issue for me on Win8 using current Nightly:

- Ensure the "Disable display scaling" compatibility setting is NOT selected for firefox.exe, plugin-container.exe, or the FlashPlayer*.exe plugin

- Set the Windows display scaling option to 150% or larger, and confirm that "Windows XP style scaling" is NOT selected.

- Run Nightly, and load the testcase from this bug (attachment 743616 [details]). Disable the mixed-content protection, so that the flash video loads.

- Point the mouse at the title (GTA4:...) at the top of the video, and move it around that area.

- Expected result: the title is underlined whenever the mouse hovers over it.

- Actual result: the underlining appears only very erratically as the mouse pointer moves across the title area.

If you either set the "Disable display scaling" compatibility option OR ensure that "Windows XP style scaling" is turned ON (which is the default at 125% or less), the hover effect behaves correctly.

(BTW, note that the Win8 control panel does not seem to allow me to change ONLY the "XP style scaling" option without actually changing the scale factor as well; it doesn't recognize that anything has changed and so won't "apply" the new setting.)

Comment 68

[Jonathan Kew [:jfkthame]]

Correction: on re-testing, I can't seem to get the "Disable display scaling" compatibility option to resolve the issue on Win8. (I thought this had worked for me previously, but I may be mis-remembering the combinations I'd tried.) However, fixing the manifest in the FlashPlayer plugin .exe *does* resolve the problem.

Comment 69

[Benjamin Smedberg]

akeybl, since it's not a regression and not an issue that affects large populations yet, I don't see why we'd track releases on it.

Comment 70

[Jonathan Kew [:jfkthame]]

bsmedberg/jet/others: can we please "escalat[e this] through the official channel" with Adobe, as advised by Jeromie in comment 52? I'm not sure what channels we have, but ISTM this is going to become an increasingly important issue as we roll out improved hidpi support for Windows in Firefox 22.

Comment 71

[Alex Keybl [:akeybl]]

bsmedberg suggests that there is no FF22-specific code change causing this, so we won't track. We do expect this to become a bigger issue over time though, as more users use HiDPI hardware. But that apparently will happen irregardless of FF22's release with HiDPI enabled.

If that's not true, please send bsmedberg/myself email.

Comment 72

[Jet Villegas (inactive)]

Looks like the Adobe bug in Comment 38 is the action required here. Please update with the status of that bug.

Comment 73

[Jeromie Clark]

An enhancement request for addressing this is on our product backlog, but has not been assigned to a release at this time.  Given the limited number of users affected by this change, and the guidance given by Benjamin, it is not currently being treated as a high-priority issue.

If your engineering management feels strongly about the issue, I'd again recommend that you have your senior management reach out to our senior management.

Comment 74

[Greg Edwards]

I think this particular issue (mouse movement bugs) deserves a bump in priority because the fix is so trivial--adding a line to your program's manifest. We've shown that this works in Comment 30 step 3.

The other issue (stage scaling not respecting browser scaling) could be less trivial but has been fixed on Mac already.

Comment 75

[Greg Edwards]

I can't replicate anymore. Is it possible Adobe silently fixed it?
(The scale is still wrong; see Bug 820831.)

Comment 76

[Jeromie Clark]

I believe that this work was completed as part of the high-DPI feature work.  Given that both this and 820831 are confirmed resolved, I'm going to close this on my end, unless there are objections.