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
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → ian
Hardware: PC → All
Version: unspecified → Trunk
Created attachment 182849 [details] 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
12 years ago
Duplicate of this bug: 771173
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).
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
You need to log in before you can comment on or make changes to this bug.