Open Bug 455164 Opened 15 years ago Updated 1 year ago

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

Categories

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

Product:
Core
Component:
Layout: Form Controls
Type:
defect

Tracking

()

People

(Reporter: Peter6, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(4 files)

testcase
403 bytes, text/html
Details
testcase2
1.84 KB, text/html
Details
Testcase with scale transform, shows the options being shown in the wrong place at the wrong size
251 bytes, text/html
Details
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.
59 bytes, text/x-review-board-request
Details
Attached file 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
Summary: -moz-transform rotate does not rotate the options of a selectbox → -moz-transform:rotate does not rotate the options of a selectbox
Component: Style System (CSS) → Layout: Form Controls
QA Contact: style-system → layout.form-controls
OS: Windows XP → All
Hardware: PC → All
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.
fwiw, WebKit, OS X doesn't rotate them either.
Attached file 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.
Yeah OK, we should probably set GetTransformMatrix for popups to do something reasonable.
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
Summary: -moz-transform:rotate does not rotate the options of a selectbox → CSS transforms do not apply to the options of a selectbox
Blocks: 824464
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.
See Also: → 924325
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>
Updating title to reflect current status of bug.
Summary: CSS transforms do not apply to the options of a selectbox → CSS transforms (that are more than just translations) do not apply to the options of a selectbox
Confirmed in two different mozilla browsers / OS's:
    Firefox 29.0 - Linux
    Firefox 35.0.1 - Windows
Just confirmed this is still a bug with 37.0.1 on Mac.

This has been around since 2008, really? Any workarounds?
Blocks: 1177007
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.
Problem still exists on version 44.0.2. Solution (or workaround) is to use a non-standard select box, using divs.
Happens on agar.io when selecting game mode
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
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
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?
Flags: needinfo?(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.
Flags: needinfo?(mconley)
Thanks.  I guess I'll mark a dep on bug 1331725 but chances are we'll just turn on e10s everywhere first...
Depends on: 1331725
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.
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.
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.
AFAIK, no other browser supports things like rotating the select popup, so while cool, it's a low priority to support.
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.  :(
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>)
Priority: -- → P3
Severity: normal → S3

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.

Flags: needinfo?(emilio)
Flags: needinfo?(emilio)

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

You need to log in before you can comment on or make changes to this bug.