document.getElementById(...).value returns reversed string under certain circumstances

RESOLVED FIXED in mozilla2.0

Status

()

Core
Editor
--
minor
RESOLVED FIXED
7 years ago
6 years ago

People

(Reporter: ytkvjehvsiep, Assigned: Ehsan)

Tracking

1.9.2 Branch
mozilla2.0
x86
Windows XP
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(status1.9.2 wontfix)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

7 years ago
User-Agent:       Opera/9.80 (Windows NT 5.1; U; en) Presto/2.7.62 Version/11.01
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.14) Gecko/20110218 Firefox/3.6.14

document.getElementById(...).value will return the reversed value from an input element with font-size 0.


Reproducible: Always

Steps to Reproduce:
1. Run the attached SSCCE.
2. Type in a string; the string will be echoed reversed.
3. Change the font-size at the bottom of the HTML to anything other than 0
4. Type in a string
5. String will be echoed correctly

Actual Results:  
Echoed string is reversed when font-size is 0.

Expected Results:  
String should have been echoed as-is.

This SSCCE uses Google's CDN-cached jQuery, but it has been shown to not be a jQuery bug.
(Reporter)

Comment 1

7 years ago
Created attachment 516715 [details]
SSCCE that exposes odd behaviour in document.getElementById(...).value

Comment 2

7 years ago
Works for me using Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b13pre) Gecko/20110303 Firefox/4.0b13pre ID:20110303030406

Can you try with the latest nightly please:
http://nightly.mozilla.org/
(Reporter)

Comment 3

7 years ago
Yep, works fine with the latest Minefield.

Wonder what the problem was...

Comment 4

7 years ago
If you were curious as to what fixed it, you could always try finding the regression range:
http://harthur.github.com/mozregression/

:-)
Component: General → DOM: Core & HTML
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → 1.9.2 Branch

Updated

7 years ago
Whiteboard: [fixed in gecko2.0; 1.9.2 wontfix?]
Looks like this got fixed in http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=84ee6bc0484d&tochange=5588c9796f0b

Maybe Ehsan's changes?  Not sure.

In any case, we're not going to mess with the 1.9.2 branch here.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Component: DOM: Core & HTML → Editor
QA Contact: general → editor
Resolution: --- → WORKSFORME
(Assignee)

Comment 6

7 years ago
Created attachment 516988 [details]
More minimized testcase

I have no idea what has fixed this, but I'm going to add an automated test which makes sure that this won't fail again.
Assignee: nobody → ehsan
Attachment #516715 - Attachment is obsolete: true
(Assignee)

Updated

7 years ago
status1.9.2: --- → wontfix
Flags: in-testsuite?
Resolution: WORKSFORME → FIXED
Whiteboard: [fixed in gecko2.0; 1.9.2 wontfix?]
(Assignee)

Comment 7

7 years ago
Created attachment 516990 [details] [diff] [review]
Test case
Attachment #516990 - Flags: review?(roc)
(Assignee)

Updated

7 years ago
Depends on: 610267
Whiteboard: [post-2.0][needs landing]
(Assignee)

Comment 8

7 years ago
Test case: http://hg.mozilla.org/mozilla-central/rev/5f7ab12daeb4
No longer depends on: 610267
Flags: in-testsuite? → in-testsuite+
Whiteboard: [post-2.0][needs landing]
Target Milestone: --- → mozilla2.0
No longer blocks: 770422
You need to log in before you can comment on or make changes to this bug.