Open Bug 293186 Opened 19 years ago Updated 2 years ago

scrollLeft does not force a scroll when applied to INPUT TYPE TEXT form element

Categories

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

Product:
Core
Component:
DOM: Core & HTML
Type:
defect

Tracking

()

People

(Reporter: roman_mir, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: testcase)

Attachments

(1 file)

Reporters testcase
273 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.6) Gecko/20050317 Firefox/1.0.2

Trying to use scrollLeft in javascript to force an INPUT TYPE TEXT form element
to scroll its contents but the value of the text field is not scrolling.  Same
results found in FF 1.0.2 and FF 1.0.3

Reproducible: Always

Steps to Reproduce:
1. Create an HTML file with the following contents:

<HTML>
<BODY>
<FORM NAME="TOPFORM">
<INPUT TYPE=TEXT SIZE=20 NAME="TEXTBOX">
<INPUT TYPE=BUTTON onclick="document.forms[0].TEXTBOX.scrollLeft=100"
VALUE="SCROLL TEXT">
</FORM>
</BODY>
</HTML>

2.  Open the file in FF, type some text into the text field on the page, make
sure to type more text into the field than the field's length.  Press 'Home' key
to move the cursor to the beginning of the text.
3.  Click on the 'SCROLL TEXT' button.

No results.
Actual Results:  
Nothing changed on the page

Expected Results:  
The browser should have scrolled the text within the box by 100 pixels to the left.
Seing this as well using latest trunk build (20050506) on xp, confirming.
Assignee: nobody → general
Status: UNCONFIRMED → NEW
Component: General → DOM: Level 0
Ever confirmed: true
Keywords: testcase
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → ian
Hardware: PC → All
Version: unspecified → Trunk
Attached file Reporters testcase — 
Click on the button, it sets the scrollLeft of the text field to 100. In IE it
moves 100px, in mozilla, nothing happens
The input itself is not overflowing and isn't scrollable, so the behavior is
correct as far as it goes....
This seems to be a bug in IE, see the documentation:
http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/scrollleft.asp

It clearly says:
This property is always 0 for objects that do not have scroll bars. For these
objects, setting the property has no effect.

See bug 62536, comment 45
Blocks: 343143
Assignee: general → nobody
QA Contact: ian → general
But it is useful, we can scroll/or detect visible area
Chrome and IE supports it
There is a side effect to this issue:  

When you are trying to calculate a scrollWidth vs clientWidth equation using an element that does not have overflow set to hidden/auto, you have to flip the overflow value to hidden/auto then make the calculation and then flip it back. This is done ONLY for firefox.. no other browser forces this equation. 

The problem with this equation is that flipping overflow causes two major side effects:  

(1) Firefox will re-render fonts embedded with @Font-Family for anything inside an Iframe. So, if you have a dashboarding type of application or any legacy application filled with iframes and custom fonts - this will cause the fonts to flicker heavily. This becomes increasingly painful if it is inside a timeout style calculation where the ScrollWidth is being evaluated on a consistent basis. 

(2) Modifying the overflow attribute will cause any input text element to lose focus. If you have an end user trying to select text in an input field and you modify the overflow - the user will be unable to select the text as the selection breaks upon losing focus. 

This deviation from the behavior imposed by other browsers has made it very difficult to implement custom scrollbars inside of FireFox, especially when working with legacy applications.
Currently using 16.0.2 - I've created a jsfiddle project to show the behavior that flipping the overflow produce.

http://jsfiddle.net/dacrazycoder/635J7/11/

In order to test - attempt to select the text inside the text input box. Focus will break as the overflow flips every 500 ms in order to calculate the scrollHeight.
Comment 8 and comment 9 have nothing to do with this bug, at first glance.  This bug is about setting scrollLeft on a text input.  The testcase linked to in comment 9 has no sets of scrollLeft at all.

Please file a separate bug on whatever issue those comments are about, with a clear explanation of exactly what the problem is (and in particular, a clear explanation of the "only for Firefox" bit).
Bug 717878 seems to fix this bug.
Depends on: 717878
https://bugzilla.mozilla.org/show_bug.cgi?id=1472046

Move all DOM bugs that haven’t been updated in more than 3 years and has no one currently assigned to P5.

If you have questions, please contact :mdaly.
Priority: -- → P5
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: