Closed Bug 927392 Opened 7 years ago Closed 7 years ago

‘Activate Flash’ placeholder blocks site menus

Categories

(Core :: Plug-ins, defect)

24 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: Smylers, Unassigned)

References

Details

Attachments

(2 files)

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:24.0) Gecko/20100101 Firefox/24.0 (Beta/Release)
Build ID: 20130911155223

Steps to reproduce:

The ‘Activate Adobe Flash’ placeholder has a higher z-order than the Flash plug-in its replacing, meaning that site content, such as drop-down menus, can end up behind the placeholder, and hence be unusable.

Ensure plugins.click_to_play is true, the Flash plug-in is installed, and Flash is set to ‘Ask to Activate’. Then go to http://www.eleanorlaing.com/ and hover the mouse over the ‘Contact Eleanor ▾’ entry in the site's menu bar.


Actual results:

The drop-down menu appears, but it drops down behind the ‘Activate Flash’ placeholder, making it unreadable.


Expected results:

The menu should've dropped down in front of the placeholder, like it does with actual Flash content. To see this, click on the placeholder and activate Flash for that site. Now hover over the menu items again, and see them drop down over the Flash content.
Component: Untriaged → Plug-ins
Product: Firefox → Core
This is an intentional side effect of bug 752516. If you either activate the plugin, or close it using the close box, the ordering should revert to the correct behavior.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Kindly reopen this bug. Firefox is preventing users from using websites properly.
No, this has nothing to do with Flash being there or not.
Attachment #8345917 - Flags: review+
Attachment #8345917 - Flags: feedback+
Flags: needinfo?
Comment on attachment 8345917 [details]
Proof that Firefox is "illegally" blocking functionality. http://www.huffingtonpost.com/2012/01/09/taiwan-garbage-trucks-music_n_1195020.html#comments

Due to this bug, it is covering up critical buttons.

The user cannot proceed.
Attachment #8345917 - Flags: review+
Attachment #8345917 - Flags: feedback+
(In reply to jidanni from comment #4)
> Due to this bug, it is covering up critical buttons.
> 
> The user cannot proceed.

The click-to-play overlays i see on that site can be closed fine with the close button (x). That's intended behavior (see comment 1).
Are you seeing something different? 
If yes, how do you trigger it?
Flags: needinfo?
THE USER does not dare or ever think to click on [X]'s on such unrelated parts of the web page for fear of damaging something.

I never thought of clicking on those [X]'s! (OK I might try that one day.)

The user very well might be in delicate form entry, and one mistake might throw his typing into the trash or send a half filled purchase order.

There is one workaround I found. CTRL++ many times until the buttons finally are revealed.

Anyway covering things up is just crazy.

Anyway it is easy to trigger.

Just like my Ohare attachment above. I'm sure you can reproduce that.

Well that the user can just brush off. But one day when it covers up a submit button... that's when it's going overboard.
The user might think clicking those [X]'s might start the Flash... who knows. Anyway four out of five users are just trying to get the box ALONG with its little [X] out of their way intact, and won't go clicking on unknown flash related landmines.
Indeed even if there was a comforting mouseover message at that [X], few would think of putting their mouse there to find out.

And even if it was changed to a Remove_this_box big link, people shouldn't be required to click things in order to get them from blocking other things that they shouldn't be blocking in the first place.

Nor should they need to tell whoever runs the site that their HTML is bad, assuming that any of the parties involved know what HTML is, etc. etc.
Flashs prevalence is one of the reasons why it won't CTP by default soon. In general though, the expected common case for CTP is to activate the plugin.
For those cases where you really don't want that, you can remove the element (using the x or context menu).

If you think the UI to remove the element is too subtle, that's a separate issue that we should discuss in a new bug.
The general issue of this bug is solved with bug 976769, so maybe this should be set as duplicate.

The issue of the site in comment 2 is addressed in bug 979318.
The bug was filed when we had different behavior (force plugin element on top and completely hide the overlay on close icon clicks).
The mentioned bugs are follow-ups to the regression from bug 853973, so i don't think we need to dupe here after the fact.
You need to log in before you can comment on or make changes to this bug.