455164 - CSS transforms (that are more than just translations) do not apply to the options of a selectbox

Status: NEW

(Core :: Layout: Form Controls, defect, P3)

Description

[Peter van der Woude [:Peter6]]

Attachment: testcase

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b1pre) Gecko/20080913044540 Minefield/3.1b1pre ID:20080913044540

repro: open testcase and click on the selectbox


result: the options aren't rotated

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

This is very hard to fix (especially if we were to use more native-looking dropdowns in Mac/GTK) and I don't think we should even try.

Comment 2

[philippe (part-time)]

fwiw, WebKit, OS X doesn't rotate them either.

Comment 3

[Martijn Wargers (dead)]

Attachment: testcase2

But hovering over the select popup doesn't make the items selected, that is at least clearly a bug. Also, clicking in the top right of the select element doesn't seem to make the popup appear. I'm also seeing painting errors after the popup has disappeared.

Testcase2 also shows a bug, when opening the popup, the menuitems don't get a hovered look while hovering over them. Instead, you need to take the rotation into account to get the hovered look.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Yeah OK, we should probably set GetTransformMatrix for popups to do something reasonable.

Comment 5

[[:philipp]]

according to a poster in the sumo forum -moz-transform:scale now works in IE, chrome & safari - but not still not in firefox.
https://support.mozilla.org/de/questions/928067

Comment 7

[obsidian69]

I have a dynamic form/select based menu system on a flat mounted screen where 1 user sees the menu in a frame in normal orientation & the user opposite sees the same menu inverted as the frame has a class which applies moz-transform: rotate (180).

This bug renders the menu useless on Firefox as the popup selection is not rotated.

Comment 10

[marcel.guenther81]

A scaled DIV is containing two select boxes. Due to scaling the select boxes are changing position. But after opening the select box the options are display at the position it would be without scaling the parent div

please check Fiddel: http://jsfiddle.net/wJ4H9/

code:

<div style="transform: scale(0.8);transform-origin: center center 0px; position:absolute; top:0; left:0; bottom:0; right:0;">
    <select style="position:absolute; top:50%; left:50%"> 
        <option>1</option>
        <option>2</option>
    </select>

    <select style="position:absolute; top:60%; left:30%"> 
        <option>1</option>
        <option>2</option>
    </select>
</div>

Comment 11

[Timothy Nikkel (:tnikkel)]

Updating title to reflect current status of bug.

Comment 12

[John]

Attachment: Testcase with scale transform, shows the options being shown in the wrong place at the wrong size

Comment 13

[etbz]

Confirmed in two different mozilla browsers / OS's:
    Firefox 29.0 - Linux
    Firefox 35.0.1 - Windows

Comment 14

[Tim Kelty]

Just confirmed this is still a bug with 37.0.1 on Mac.

This has been around since 2008, really? Any workarounds?

Comment 16

[Adam E Hutchins]

I ran into this bug in my work and I am very surprised to see that it has been a problem for 7 years. I'm using transform: scale() to create a zoom-in/zoom-out effect on certain divs. Some of them have select elements and this bug makes it so that the options for the select can actually appear off of the screen. 

See Fiddle:
https://jsfiddle.net/g66tLhou/

Notice that when inspecting the option elements (right click -> Inspect Element), the box model of the option appears in the right place, with the right size.

Comment 20

[Chuong Duong]

(In reply to Tim Kelty from comment #14)
> Just confirmed this is still a bug with 37.0.1 on Mac.
> 
> This has been around since 2008, really? Any workarounds?

A workaround is using chrome instead of firefox :)

Firefox 41.0.1 for linux still has this problem

Comment 21

[Benjamin Silver]

(In reply to Chuong Duong from comment #20)
> (In reply to Tim Kelty from comment #14)
> > Just confirmed this is still a bug with 37.0.1 on Mac.
> > 
> > This has been around since 2008, really? Any workarounds?
> 
> A workaround is using chrome instead of firefox :)
> 
> Firefox 41.0.1 for linux still has this problem

Haha indeed, the solution is to use a modern browser ;p

Comment 23

[andreipop2005]

Problem still exists on version 44.0.2. Solution (or workaround) is to use a non-standard select box, using divs.

Comment 24

[Hallvord R. M. Steen [:hallvors]]

Happens on agar.io when selecting game mode

Comment 27

[arni2033]

Two wrong things in this bug report:

1) The way every bug ends up a duplicate of this bug is wrong. Half of "duplicates" say that options
   popup appears in an unexpected location (that's all!). That is what definitely should be fixed.
   While _this_ bug requests something unclear. See comment 1 - "I don't think we should even try"
   Even Firefox developers don't know if they want to fix _this_ bug. There's even no bug/comment
   saying "decide what types of transform should be applied to the drop-down".

   There're 2 separate bugs: [1] location of drop-down (bug 1297422)   [2] transform of drop-down
   So referring to them as one (this) bug is wrong.

2) There's no indication here that [1] doesn't manifest in content process (e10s).
   Nobody will read the duplicates (that's for sure), so it should be mentioned in this bug report

Comment 28

[mr.andrewwebster]

My team came across an issue today that seems related to this, found the source of the issue to be the perspective option on our transform.

The transform was being applied to a modal with select and option elements within.

Example:
http://codepen.io/mr_webster/pen/GNwPLK

Comment 29

[Boris Zbarsky [:bzbarsky]]

This seems to be fixed in e10s mode.

Mike, I assume that's expected because we're no longer doing the weird native widget thing there?  Do we have a tracker for combobox bugs fixed in e10s?  Are we just marking them as fixed, or waiting until e10s is always on?

Comment 30

[Mike Conley (:mconley) (:⚙️)]

(In reply to Boris Zbarsky [:bz] (still a bit busy) (if a patch has no decent message, automatic r-) from comment #29)
> This seems to be fixed in e10s mode.
> 
> Mike, I assume that's expected because we're no longer doing the weird
> native widget thing there?  Do we have a tracker for combobox bugs fixed in
> e10s?  Are we just marking them as fixed, or waiting until e10s is always on?

Sorry for the delay in response.

Yeah, this is because we're doing the drawing of the popup in the parent process. There's a bug (bug 1331725) to turn on the same abilities for non-e10s, but as I recall there are still some a11y issues to work out and some failing tests. I guess it's currently a race between that bug and having e10s be the default operating mode.

Comment 31

[Boris Zbarsky [:bzbarsky]]

Thanks.  I guess I'll mark a dep on bug 1331725 but chances are we'll just turn on e10s everywhere first...

Comment 32

[Jared Wein [:jaws] (please needinfo? me)]

This should now be fixable via the same route that bug 910022 went, by forwarding the computed styles to the parent process and applying them there. The number of forwarded styles continues to grow, so while we could simply do this, there will come a time when the amount of styles that are being forwarded slows down the content->chrome messages.

Comment 33

[Boris Zbarsky [:bzbarsky]]

This bug is about the placement of the dropdown not matching the placement of the <select> on the page.  It's already fixed in the e10s case; there's nothing to be done there.

Comment 34

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Bug 455164 - Proof-of-concept of applying transform to the popup. This attempts to fix attachment 338465 but the popup is clipped on the parts that extend outside of the normal menupopup rectangle.

Review commit: https://reviewboard.mozilla.org/r/134478/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/134478/

Comment 35

[Jared Wein [:jaws] (please needinfo? me)]

Yes, well attachment 338465 [details] on e10s doesn't show a rotated popup. I just attached a rough proof-of-concept that shows how we could do this, but (at least on Windows) we are clipping the popup for all parts that are outside of the non-transformed menupopup rect.

Comment 36

[Timothy Nikkel (:tnikkel)]

AFAIK, no other browser supports things like rotating the select popup, so while cool, it's a low priority to support.

Comment 37

[Boris Zbarsky [:bzbarsky]]

I guess the original bug here was about rotating the dropdown, but then people dupped all sorts of bugs about "the dropdown is in the wrong place" here, incorrectly.

What we should probably do is open a new clean (but possibly wontfix) bug on the original thing this bug was filed on.  :(

Comment 40

[619076648]

Please browse website:http://www.pre100.com/xxdt/,Using different browsers,click the drop-down button which go to page(Flip),You'll find out firefox error(The numbers in the drop-down list box misplaced),firefox Upgraded 54.0.1.the HTML control: the sub item  <select>label:<option> will be misplaced(<select><option>…</option> </select>)

Comment 41

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 11 duplicates and 21 votes.
:emilio, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 42

[Timothy Nikkel (:tnikkel)]

Did we fix this when we moved to parent process select boxes?