542375 - the clientWidth of a Textarea with 0px height reports incorrect results right after its .value and the .style.width are changed

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[kkapsner]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2) Gecko/20100115 Firefox/3.6

See this JavaScript-code (this is performed in the link):

window.onload = function(){
	var t = document.getElementsByTagName("textarea")[0];
	alert(t.clientWidth);
	t.value = "";
	t.style.width = "200px";
	alert(t.clientWidth); //incorrect
	var z = t.style.zIndex;
	t.style.zIndex = "1";
	alert(t.clientWidth); //now it's correct
	t.style.zIndex = z;
	alert(t.clientWidth); //stays correct
}

Reproducible: Always

Steps to Reproduce:
1. Execute the code
2. See what you get
Actual Results:  
alerts:

178
178
200
200

Expected Results:  
alerts:

178
200
200
200

Comment 1

[Ria Klaassen (not reading all bugmail)]

Confirmed with latest trunk on Windows Vista. This worked fine with Firefox 3.5.

Comment 2

[Matt]

(In reply to comment #1)
> Confirmed with latest trunk on Windows Vista. This worked fine with Firefox
> 3.5.

Latest trunk works fine for me on Windows 7.

works:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100128 Minefield/3.7a1pre
Results: 179 200 200 200

works:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a2pre) Gecko/20100216 Minefield/3.7a2pre
Results: 179 200 200 200


These regression ranges might not be true on other operating systems.

Regression range:

works:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090803 Minefield/3.6a1pre
http://hg.mozilla.org/mozilla-central/rev/51f332235f14
Results: 179 200 200 200

broken:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090804 Minefield/3.6a1pre
http://hg.mozilla.org/mozilla-central/rev/3ce467cf8e0d
Results: 179 179 200 200

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=51f332235f14&tochange=3ce467cf8e0d


Regression range 2:

broken:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091029 Minefield/3.7a1pre
http://hg.mozilla.org/mozilla-central/rev/ac98fd60de44
Results: 179 179 200 200

broken - different:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091030 Minefield/3.7a1pre
http://hg.mozilla.org/mozilla-central/rev/001e14d17a30
Results: 179 179 179 179

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ac98fd60de44&tochange=001e14d17a30


"Fixed" range:

broken - different:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091111 Minefield/3.7a1pre
http://hg.mozilla.org/mozilla-central/rev/2eb351cc47d3
Results: 179 179 179 179

works:
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20091112 Minefield/3.7a1pre
http://hg.mozilla.org/mozilla-central/rev/6628da386550
Results: 179 200 200 200

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2eb351cc47d3&tochange=6628da386550

Comment 3

[Nickolay_Ponomarev]

So judging from the regression windows, I guess:
- bug 502288 could be responsible for the original regression
- bug 507764 made zIndex changes from script not reflow.
- From the third range, bug 259636 sounds the most related, but I don't see how it could fix this.

bz, does this sound plausible? Do you think anything should be done about this, given the regression is 1.9.2-only?

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: reporter's testcase

Current contents of http://kkjs.kkapsner.de/tests/FF-textarea-Bug.html

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

It seems like it's still broken if I don't change .value (i.e., remove the t.value = "" line from the testcase), though.

Comment 6

[Boris Zbarsky [:bzbarsky]]

At least on Mac, this worksforme with the url in the url field (and of course the comment 4 testcase).  Is this windows-only?

Comment 7

[Nickolay_Ponomarev]

Hmm, yes, I can reproduce on 
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (179, 179, 200, 200)

but not on:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3 (173, 200, 200, 200)

Comment 8

[Boris Zbarsky [:bzbarsky]]

That's somewhat odd.  Do you have a Windows debug build, perchance?

Comment 9

[Nickolay_Ponomarev]

Not from 1.9.2 brach, no.

BTW, I suspected it could be due to alert()s, so I made a version that only alerts after the script has run: http://mozilla.doslash.org/stuff/bug542375.html -- but it gives the same results on 3.6.3.

With that new version I also noticed that Windows *trunk* alerts 179,179,179,179 when using Undo Close Tab (but again not Mac)...

Comment 10

[Boris Zbarsky [:bzbarsky]]

Do you have a windows trunk debug build?

If so, can I see a frame dump from after that undo close tab?

Comment 11

[Nickolay_Ponomarev]

> If so, can I see a frame dump from after that undo close tab?
I answered in a new bug (bug 563416), since it's a different issue.

Comment 12

[Boris Zbarsky [:bzbarsky]]

OK.  I think it's the same underlying problem, so marking dependency....

Comment 13

[Mats Palmgren (inactive)]

I've made 1.9.2 TryServer builds with the fix in bug 563416 for testing:
https://build.mozilla.org/tryserver-builds/[e-mail]-563416-192/

Comment 14

[Mats Palmgren (inactive)]

Fixed by bug 563416.