209807 - [FIXr]input.scrollWidth and input.scrollHeight returning wrong values

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P1)

Description

[David Anderson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030612

I know this sucks as a bug report.  However, I had a javascript that calculated
positioning using offsetleft, offsettop which worked fine in 1.3 but is broken
now.  I know there have been a lot of invalid bugs like this.  I'll try to work
up a testcase soon.  It's just so close to the 1.4 release that I thought I'd
put this in now. ( I was using firebird and thought that it might just be fb,
but that's not the case. )

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[David Anderson]

scrollWidth and scrollHeight are returning wrong values...

that was the problem

added attachment, changed summary.

Comment 2

[David Anderson]

(sorry, the 'attachment' is the url.)

Comment 3

[Mats Palmgren (inactive)]

Attachment: Testcase #1

Comment 4

[Mats Palmgren (inactive)]

-> DOM extensions

Comment 5

[Christopher Aillon (sabbatical, not receiving bugmail)]

Does this happen for all elements or just input?

Comment 6

[David Anderson]

Attachment: Testcase #2 (divs no affected, unstyled input is)

Only text and password types are affected.
Testcase #2 tests text, password, checkbox, radio, button, div, p, textarea.

Ps. Note, the problem affects even unstyled input-text boxes.

Comment 7

[Boris Zbarsky [:bzbarsky]]

The problem here is that nsTextControlFrame implements nsIScrollableViewProvider
and the view it returns if it's a single-line text control is totally bogus (see
nsTextControlFrame::GetScrollableView).

There are two possible fixes to this bug:

1)  Always just return mScrollableView
2)  Don't QI to nsIScrollableViewProvider if we are not scrollable.

roc, do you have any idea what this code is trying to do and why?

Comment 8

[Boris Zbarsky [:bzbarsky]]

This got broken by blake with his patch to bug 62431.  Ccing blake and reviewers
of the patch.  I suspect that approach #2 would fix that bug without causing
this bustage.  I can't test for sure, because I don't have a mousewheel to test
with.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Possible patch, untested

Can someone who has a scrollwheel check that this does not regress bug 62431? 
Blake, could you take a few mins to do that?

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 141728 [details] [diff] [review]
Possible patch, untested

OK, this patch fixes the bug.  I still can't test its effect on bug 62431, but
it should be fine, since the text control will no longer have a scrollview.

Comment 11

[Christian :Biesinger (don't email me, ping me on IRC)]

this patch does not change mozilla's behaviour wrt mousewheels on inputs and
textareas. tested on current trunk, winxp.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Fix checked in for 1.7b