385615 - {inc} style of :first-letter used to erroneously calculate (intrinsic) width of element

Status: NEW

(Core :: Layout, defect)

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase, when clicking on the button, it shrinks.
Although the end result looks more correct to me, the button should not change size when clicking on it.

Comment 1

[nemo]

Attachment: testcase with a floated block with first-letter

Another testcase, on a div this time.  Button sets then removes a padding.

Comment 2

[nemo]

Attachment: fix of javascript in prior attachment

removed invalid styling "none" and added a setTimeout since otherwise it didn't apply the styling.

Comment 3

[nemo]

Also odd, is that in the (fixed) attachment after triggering recalc, there is still some white space to the right inside the div.

Comment 8

[RNicoletto]

Possible workaround: https://addons.mozilla.org/firefox/addon/bug385615/

Comment 11

[Roman Komarov]

Attachment: Some more test-cases with different font-sizes and floating first-letters

Attached some more test-cases.

What I can see: with larger font-size the bigger extra width would be, the more letters after the first, again the bigger the extra width would be.

Adding float to first-letter invert this behavior, but the extra would depend only on the font-size of the first letter.

And if the font-size of the first-letter is lesser than the inline-block's, then the width of this inline-block “shrinks”.

Comment 13

[Elijah Lynn]

Want to cross link two in the wild bug reports to this issue.

http://stackoverflow.com/questions/13160161/firefox-whitespace-oddity-bug-on-a-element/

http://stackoverflow.com/questions/7548255/is-there-a-css-workaround-for-firefox-bug-inline-block-first-letter-with-cha

Comment 15

[jan dvorak]

Crosslinking another Stack overflow question: http://stackoverflow.com/questions/14130653/firefox-calculating-blocks-larger/14131771#14131771

A block-level link shrinks (recalculates its width) to the correct size when focused. All (left, right, middle) clicks trigger the fix. Tabbing onto the link triggers the fix if not prevented by Javascript. Some hover effects also fix the bug.

Manifests as an unwanted gap between floating elements.

Comment 18

[Michał Gołębiowski-Owczarek [:mgol]]

Any chance of getting it fixed soon? This bug has been open for 6 years and the styling errors caused by this bug are very visible and workarounds are so ugly... This bug is a huge PITA.

Comment 20

[m93a.cz]

Still present in FF 38. Not only "font-size" but also "text-transform" triggers the bug. I'm not sure why but in my case "uppercase" makes a way bigger bug-padding than "capitalize", although the result should be (and is in standard-compliant browsers) the same.

Comment 23

[Jonathan Kew [:jfkthame]]

This applies to any aspect of the style of ::first-letter that may affect measurement (not only font-size). E.g. it can be reproduced with text-transform, font-family, font-stretch, font-weight, letter-spacing, etc. Updating the summary to make it more general.

Comment 28

[David Baron :dbaron:]

Note that bug 362880 comment 2 has some thoughts on how to fix this.

Comment 33

[Alice0775 White]

(sorry, maybe off-topic)
Interestingly, If I installed Glitter Drag[1] extension, the problem is gone.
[1]https://addons.mozilla.org/en-US/firefox/addon/glitterdrag/

Comment 37

[Release mgmt bot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 38

[Release mgmt bot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.