Open
Bug 562868
Opened 15 years ago
Updated 3 years ago
button hover with moz-box-shadow resizes input elements
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
UNCONFIRMED
People
(Reporter: joe.vannucci, Unassigned)
References
(Depends on 1 open bug)
Details
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2.5pre) Gecko/20100429 Namoroka/3.6.5pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2.5pre) Gecko/20100429 Namoroka/3.6.5pre
Minimal test case:
HTML:
<body>
<input id="btn" type="button" value="blah" />
<input type="text" />
</body>
CSS:
#btn { -moz-box-shadow: 0 4px 6px rgba(18,14,16,0.2); }
#btn:hover { -moz-box-shadow: 0 4px 6px rgba(13,14,16,0.2); }
It seems that any slight difference in box shadow specification between normal and hover will produce the problem. In this case I've just changed the "R" portion of the rgb color slightly, from 18 to 13.
When hovering over the button, the button, and the input field "shrink" if the input field has focus, and expand if it does not.
The problem does not occur if the button and text input do not share the same immediate DOM parent. (My workaround was to put the text input into a div styled with display:inline-block.)
Reproducible: Always
Steps to Reproduce:
1. Create HTML and CSS per above description.
2. Load the page.
3. Click to set focus on the text input element.
4. Hover mouse over button.
5. Click on empty portion of page to take focus away from input element.
6. Again hover mouse over button.
Actual Results:
Try the steps a few times. You'll see that when the input box has focus, hovering over the button triggers the "shrink", where BOTH elements seem to get smaller and/or move up by one or two pixels.
When the input box does not have focus, hovering triggers the elements to expand back to their previous sizes.
Expected Results:
The elements should not change size.
Change the single digit difference in the box-shadow css so the normal and hover are the same. The problem no longer exists.
|
||
Comment 1•15 years ago
|
||
With this testcase, I don't see the problem on Mac, with either 1.9.2 or trunk... Do you see the problem with this page? If not, can you attach a page that does show the problem?
|
|
Reporter | |
Comment 2•15 years ago
|
||
This attachment shows the problem. In my original write up I neglected to mention the text element has a :focus style.
|
|
Reporter | |
Comment 3•15 years ago
|
||
Sorry for the separate comment, I'm new to bugzilla...
Boris, your example doesn't demonstrate the problem for me either. My original test case was invalid. It should be:
<style>
#btn { -moz-box-shadow: 0 4px 6px rgba(18,14,16,0.2); }
#btn:hover { -moz-box-shadow: 0 4px 6px rgba(13,14,16,0.2); }
#txt:focus { background-color: #ff6; }
</style>
<body>
<input id="btn" type="button" value="blah" />
<input id="txt" type="text" />
</body>
Additionally, poking around with firebug on 3.6.3 shows that the button doesn't change size. It does move to remain in vertical alignment with the text element. The text element appears to sometimes vary width and height by 2px each, and at other times the border varies from 1px to 2px. And sometimes neither, and sometimes both at once.
Sorry for the bad initial test case.
|
|
||
Comment 4•15 years ago
|
||
Ah, ok. Setting background-color on the text input switches it from being native-themed to not native-themed. Native theming includes border and padding sizes, so the size of native themed inputs may not match non-native-themed ones. There's an existing bug about not recomputing sizes immediately when native theming drops: bug 393325.
Once that's fixed, the size will change as soon as you focus the textfield, as it should.
Depends on: 393325
|
|
Reporter | |
Comment 5•15 years ago
|
||
Ok, thanks. I know zip about native themes, and I understand this is expected behavior (once 393325 is fixed).
But... wouldn't it better follow the path of "least surprise" to leave the pertinent native theme css attributes in place, and just modify the ones specifically changed? For instance, in my example, I didn't set a border width, but setting a background color causes border width to change.
|
|
||
Comment 6•15 years ago
|
||
Native theme engines don't provide us with info like border widths etc. All they can do is draw a bitmap of the whole control "background" (which in their case includes borders) into a location on the screen we specify. So as soon as you change any of the things the theme engine draws (borders, backgrounds) we have to stop using it.
With native theme, we're just telling the OS to draw a button. We either do that or draw it ourselves. I'm not sure if we could get reliable code across platforms to extract what we think the border or background of what the OS draws is.
|
|
Reporter | |
Comment 8•15 years ago
|
||
Thank you both for the education, and for taking the time to respond.
|
||
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•