Closed Bug 1250824 Opened 9 years ago Closed 9 years ago

ScrollWidth wrong on element with overflow:hidden + text-overflow: ellipsis

Categories

(Core :: DOM: CSS Object Model, defect)

44 Branch
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: nathan.burgherr, Unassigned)

Details

(Whiteboard: btpp-followup-2016-03-10)

Attachments

(5 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36 Steps to reproduce: See example on https://jsfiddle.net/9ez4x0vy/ Actual results: Ellipsis is done correctly because text does not fit into label, but the value in elem.scrollWidth seems to be wrong, it's equal to elem.clientWidth. This calculation of scrollWith fails only when the original text does not fit because of 1-3 px. Expected results: elem.scrollWidth should be bigger than elem.clientWidth
Similar bug in the past: bug 833542.
Component: Untriaged → DOM: CSS Object Model
David, do you have thoughts here?
Flags: needinfo?(dbaron)
Whiteboard: btpp-followup-2016-03-03
Redirecting needinfo to Mats. No thoughts here other than that we should probably be compatible with what other browsers do, unless what other browsers do is nonsense *and* the Web doesn't depend on it.
Flags: needinfo?(dbaron) → needinfo?(mats)
Attached file testcase (deleted) —
I can't reproduce the problem, neither in Nightly nor in v44. On my system (Linux) I get these results: ClientWidth: 10 ScrollWidth: 12 ClientWidth: 11 ScrollWidth: 12 ClientWidth: 12 ScrollWidth: 12 ClientWidth: 20 ScrollWidth: 60 ClientWidth: 55 ScrollWidth: 60 ClientWidth: 56 ScrollWidth: 60 ClientWidth: 57 ScrollWidth: 60 ClientWidth: 58 ScrollWidth: 60 ClientWidth: 59 ScrollWidth: 60 ClientWidth: 60 ScrollWidth: 60 ClientWidth: 61 ScrollWidth: 61 ClientWidth: 62 ScrollWidth: 62 All the text cases are ellipsised except the last three, which is expected since the text fits. Chrome has the same behavior, AFAICT. Maybe I just don't understand what the problem is. Perhaps you can modify this testcase so that it shows the problem?
Flags: needinfo?(mats) → needinfo?(nathan.burgherr)
Attached image Fiddle result on firefox (deleted) —
Flags: needinfo?(nathan.burgherr)
Attached image Fiddle result on chrome (deleted) —
Note that both scrollWidth and clientWidth are rounded to an integer. Perhaps that is affecting your results? What is the value of elem.getBoundingClientRect().width in your examples?
Flags: needinfo?(nathan.burgherr)
That's just what I was thinking. I have added a some new screens with the BoundingClientRect.width values https://jsfiddle.net/3emx907y/1/
Flags: needinfo?(nathan.burgherr)
Attached image BoundingClientRectChrome.PNG (deleted) —
Attached image BoundingClientRectFirefox.PNG (deleted) —
Max. # Wochen voras ClientWidth: 140 ScrollWidth: 140 Boundingrect: 140 Max. # Wochen iiiii ClientWidth: 140 ScrollWidth: 140 Boundingrect: 140 Max. # Wochen aaww ClientWidth: 140 ScrollWidth: 143 Boundingrect: 140 Max. # Wochen kkkk ClientWidth: 140 ScrollWidth: 140 Boundingrect: 140 Max. # Wochen wwww ClientWidth: 140 ScrollWidth: 152 Boundingrect: 140 Max. # Wochen vorsi ClientWidth: 140 ScrollWidth: 140 Boundingrect: 140
I tried your testcase with a few different text variations in Nightly on Windows 7 but I still couldn't reproduce it. Can you tell me what the values are for the following (in the "Max. # Wochen voras" case): elem.getBoxQuads()[0].p1.x elem.getBoxQuads()[0].p2.x elem.firstChild.getBoxQuads()[0].p1.x elem.firstChild.getBoxQuads()[0].p2.x
Flags: needinfo?(nathan.burgherr)
Whiteboard: btpp-followup-2016-03-03 → btpp-followup-2016-03-10
Max. # Wochen vo... ClientWidth: 140 ScrollWidth: 140 Boundingrect: 140 BoxQuads p1:8 BoxQuads p2:148 BoxQuads firstChild p1:8 BoxQuads firstChild p2:148.01666259765625
Flags: needinfo?(nathan.burgherr)
Max. # Wochen vo... ClientWidth: 140 ScrollWidth: 140 Boundingrect: 140 BoxQuads p1:8 BoxQuads p2:148 BoxQuads firstChild p1:8 BoxQuads firstChild p2:148.01666259765625 Max. # Wochen iiiii ClientWidth: 140 ScrollWidth: 140 Boundingrect: 140 BoxQuads p1:8 BoxQuads p2:148 BoxQuads firstChild p1:8 BoxQuads firstChild p2:135.60000610351562 Max. # Wochen aa... ClientWidth: 140 ScrollWidth: 143 Boundingrect: 140 BoxQuads p1:8 BoxQuads p2:148 BoxQuads firstChild p1:8 BoxQuads firstChild p2:150.64999389648438 Now I see the problem. It's used a mathematical round not a ceil. Is this correct? Shouldn't the scroll with be rounded up when it's bigger than the clientWidth?
Yes, we use mathematical round for both ClientWidth and ScrollWidth. AFAICT, Chrome also does that.
I'm closing this because I don't think there is anything we want to do here. The BoxQuads results in comment 14 clearly shows that there *is* overflow. (148.01666259765625 - 8 > 140) As far as I can tell we're also compatible with Chrome and specs regarding rounding behavior on ClientWidth and ScrollWidth, so I suspect the bug might also occur in Chrome given the right circumstances (font metrics etc).
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Yes there is overflow, but it's not possible to figure out if there is some. If I run the same example in Chrome the scroll width is different to that in firefox: Max. # Wochen vor.. ClientWidth: 140 ScrollWidth: 141 Boundingrect: 140 Max. # Wochen iiiii ClientWidth: 140 ScrollWidth: 140 Boundingrect: 140 Max. # Wochen aaww ClientWidth: 140 ScrollWidth: 144 Boundingrect: 140 Max. # Wochen kkkk ClientWidth: 140 ScrollWidth: 140 Boundingrect: 140 Max. # Wochen wwww ClientWidth: 140 ScrollWidth: 153 Boundingrect: 140 Max. # Wochen vorsi ClientWidth: 140 ScrollWidth: 140 Boundingrect: 140 Do you have any other idea how we can get the correct overflow, because getBoxQuads is only available in nightly. This behavior shows up a lot in our application if we run it on firefox but in other browsers everything runs fine.

Seeing this issue in our codebase when using scrollWidth and offsetWidth to determin text overflow in our dropdown components. Like the above user--this bug is not happening in Chrome/Chromium/Safari browsers seems unique to Firefox.

https://github.com/carbon-design-system/carbon/issues/8864

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

Attachment

General

Created:
Updated:
Size: