Cannot open file picker window from flash widget on x64 browser version

RESOLVED FIXED

Status

()

Core
Plug-ins
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: VladB, Unassigned)

Tracking

({64bit, flashplayer, site-compat})

46 Branch
x86_64
Windows
64bit, flashplayer, site-compat
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox46 affected)

Details

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160104030217

Preconditions:	
1. Flash plugin is installed and active.

Steps:	
1. Open http://imagevenue.com/ 
2. Click "Browse" button from the flash widget.

Expected results:	
The file picker window is displayed.

Actual results:
Nothing happens.

Notes:
1. On x86 browser version or if environment variable "MOZ_DISABLE_NPAPI_SANDBOX=1" is set, the file picker correctly opens.

Updated

2 years ago
No longer blocks: 1119376

Updated

2 years ago
Component: XUL → Plug-ins

Updated

2 years ago
Flags: needinfo?(bobowen.code)

Comment 1

2 years ago
Sorry it's taken a while to get to this.

It seems that this flash file picker is broken by low integrity and so are a couple of others I've tried.

I'm sure this worked originally, so either some are broken and not others or something else we've changed or Adobe has changed has affected it.

Ben - do we have a usual contact at Adobe to ask about such things?

I'll try and see if I can find a working version for us tomorrow, to see if it is something we've changed.
Flags: needinfo?(bobowen.code) → needinfo?(benjamin)

Comment 2

2 years ago
I've gone back to the first beta that included the 64-bit flash sandbox and versions of flash that were a while before I was working on this and they all fail.

So, maybe my testing was flawed somehow, but I know that I tested it, because for the level 3 (default is currently 2), I had to add read access back to the users directories to get it to work.
The other possibility is that an OS update has changed things, I suppose.

I don't see anything obvious in the logs that is getting blocked, but low integrity can block subtle things that we can't add rules for, so won't show up in our logging.

I'll see if I can find what is being blocked, but this will be down in flash somewhere, which obviously makes that difficult.

Without low integrity, the sandbox is probably fairly pointless I'd say.

Comment 3

2 years ago
Looks like it is bug 1165903 that caused this, so I (and nobody else) can have tested file uploading since then.

I can only guess that flash us walking up our HWND hierarchy and trying to use an HWND from the parent process.
Presumably before I got our reparenting working and fixed bug 1165903, it was just finding our child HWND and using that.

This is sort of confirmed by the fact that, if I load a file uploader with my own html and force it to windowless (wmode=transparent) then the file picker appears.
It appears at 0,0 and for some reason in the bin directory, but it does appear.

One of the proposed fixes for the IME issues was forcing windowless, not sure why that got stalled.
Blocks: 1165903

Comment 4

2 years ago
Hi have reported this bug to Adobe: https://bugbase.adobe.com/index.cfm?event=bug&id=4095131 and they said, that i should report the bug here.

Comment 5

2 years ago
(In reply to Philip Mair from comment #4)
> Hi have reported this bug to Adobe:
> https://bugbase.adobe.com/index.cfm?event=bug&id=4095131 and they said, that
> i should report the bug here.

Thanks Philip.

Bill - Brad mentioned that you have some contact with Adobe people at the moment.
If what I said in comment 3 is correct, it looks like one fix for windowed mode would be to use the HWND from the child process instead of whatever parent process HWND they are using.
Flags: needinfo?(wmccloskey)

Comment 6

2 years ago
The workaround with using wmode="transparent" is working, but this render mode causes compromising on render performance. 

We have tested previous x64 builds with Firefox and this bug seems to be related with FF >= 42.
(In reply to Philip Mair from comment #6)
> The workaround with using wmode="transparent" is working, but this render
> mode causes compromising on render performance. 
> 
> We have tested previous x64 builds with Firefox and this bug seems to be
> related with FF >= 42.

Then bug 1201904 will fix this because we are going to force windowless mode on Win64 Firefox.

Comment 8

2 years ago
(In reply to Masatoshi Kimura [:emk] from comment #7)
> (In reply to Philip Mair from comment #6)
> > The workaround with using wmode="transparent" is working, but this render
> > mode causes compromising on render performance. 
> > 
> > We have tested previous x64 builds with Firefox and this bug seems to be
> > related with FF >= 42.
> 
> Then bug 1201904 will fix this because we are going to force windowless mode
> on Win64 Firefox.

I'm sorry, but i think this is a terrible solution. Windowless mode have many side other effects. 

For example that the Flash Player is loosing the keyboard focus on context menus and does not gain it back unless you select the address bar and then the plugin again. Mouse Events are correctly routed to the plugin, but you can not enter any text unless the steps which i described.
(In reply to Philip Mair from comment #8)
> For example that the Flash Player is loosing the keyboard focus on context
> menus and does not gain it back unless you select the address bar and then
> the plugin again. Mouse Events are correctly routed to the plugin, but you
> can not enter any text unless the steps which i described.

Please file a bug about the problem.
We're working with Adobe to improve windowless plugins and eliminate windowed plugins. I think that's probably the best path forward here.
Flags: needinfo?(wmccloskey)
Flags: needinfo?(benjamin)

Updated

2 years ago
Duplicate of this bug: 1243511

Updated

2 years ago
Keywords: 64bit, flashplayer, site-compat

Updated

2 years ago
Duplicate of this bug: 1245458

Updated

2 years ago
Duplicate of this bug: 1246867
Blocks: 1165891

Updated

2 years ago
Duplicate of this bug: 1248342

Comment 15

2 years ago
hope it will be transparent if filereferenceList function is called from actionscript 2 or 3

Comment 16

2 years ago
This was fixed by bug 1201904 making the 64-bit plugins windowless.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Depends on: 1201904
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.