348809 - [FIX]Changing the type attribute of form controls needs to notify about various state changes

Status: RESOLVED FIXED

(Core :: CSS Parsing and Computation, defect, P2)

Description

[Boris Zbarsky [:bzbarsky]]

See testcases at 

http://web.mit.edu/bzbarsky/www/testcases/css-selectors/dynamicChecked-1.html
http://web.mit.edu/bzbarsky/www/testcases/css-selectors/dynamicChecked-2.html
http://web.mit.edu/bzbarsky/www/testcases/css-selectors/dynamicDefault-1.html
http://web.mit.edu/bzbarsky/www/testcases/css-selectors/dynamicDefault-2.html
http://web.mit.edu/bzbarsky/www/testcases/css-selectors/dynamicDefault-3.html
http://web.mit.edu/bzbarsky/www/testcases/css-selectors/dynamicDefault-4.html

I'll check those into our tests too, for this bug.

Note that this doesn't address bug 315920 or anything...

Comment 1

[Boris Zbarsky [:bzbarsky]]

Attachment: Like so

Comment 2

[Boris Zbarsky [:bzbarsky]]

Note that I added more testcases for this sort of thing at http://web.mit.edu/bzbarsky/www/testcases/css-selectors/ a while back; the testcases that apply to this bug are in CVS with the appropriate filenames.

Comment 3

[Robert Sayre]

when this lands, please add the tests to mochitest.

It should look pretty much like this file:
/cvsroot/mozilla/testing/mochitest/tests/test_bug302186.html

Comment 4

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

Comment on attachment 233949 [details] [diff] [review]
Like so

> nsHTMLInputElement::IntrinsicState() const
> {
>+  // If you add states here, and they're type-depedent, you need to add them to

depe*n*dent

>Index: content/html/content/src/nsGenericHTMLElement.cpp
>+      if (doc) {

 && aNotify ?

>Index: content/html/content/src/nsHTMLFormElement.cpp

r+sr=dbaron

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Updated to comments and tip, now with tests.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Checked in, with tests and trumpets.

Comment 7

[Rob Campbell [:rc] (:robcee)]

Check again! reftest.list is incorrectly referencing bugs/348801 instead of 348809. This is causing reftest to stall out.

Comment 9

[Rob Campbell [:rc] (:robcee)]

Attachment: reftest.list patch 348801->348809

Comment 10

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 254535 [details] [diff] [review]
reftest.list patch 348801->348809

That's what I get for doing this late at night... r=bzbarsky

Comment 11

[Boris Zbarsky [:bzbarsky]]

And checked in.

Comment 12

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

Attachment: 4 of the tests are failing

Now it looks like 4 of the tests are failing.  This is from the Linux test log.  The Windows log also showed 4 failures (didn't check that they were the same, though).

Comment 13

[Rob Campbell [:rc] (:robcee)]

The first of the linux tests is an easy fix. It's an extra period at the end of the line "There should be no red".

Comment 14

[Rob Campbell [:rc] (:robcee)]

incidentally, these are the same tests that are failing on windows.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix those

Yep.  The period, and three typos in the moving of onload handlers into inline script...  I _really_ shouldn't do tests at night.  :(

I checked this in.  With this, the tests pass as far as I can tell (by manual loading; running the actual test over remote X seems to be very unhappy).