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)
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
Comment 2•9 years ago
|
||
David, do you have thoughts here?
Flags: needinfo?(dbaron)
Whiteboard: btpp-followup-2016-03-03
Comment 3•9 years ago
|
||
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)
Comment 4•9 years ago
|
||
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)
Reporter | ||
Comment 5•9 years ago
|
||
Flags: needinfo?(nathan.burgherr)
Reporter | ||
Comment 6•9 years ago
|
||
Comment 7•9 years ago
|
||
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)
Reporter | ||
Comment 8•9 years ago
|
||
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)
Reporter | ||
Comment 9•9 years ago
|
||
Reporter | ||
Comment 10•9 years ago
|
||
Comment 11•9 years ago
|
||
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
Comment 12•9 years ago
|
||
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)
Updated•9 years ago
|
Whiteboard: btpp-followup-2016-03-03 → btpp-followup-2016-03-10
Reporter | ||
Comment 13•9 years ago
|
||
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)
Reporter | ||
Comment 14•9 years ago
|
||
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?
Comment 15•9 years ago
|
||
Yes, we use mathematical round for both ClientWidth and ScrollWidth.
AFAICT, Chrome also does that.
Comment 16•9 years ago
|
||
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
Reporter | ||
Comment 17•9 years ago
|
||
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.
Comment 18•3 years ago
|
||
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.
You need to log in
before you can comment on or make changes to this bug.
Description
•