WebKit Bugzilla
New
Browse
Search+
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
67745
tables/mozilla/bugs/
bug53690
-1.html has never worked
https://bugs.webkit.org/show_bug.cgi?id=67745
Summary
tables/mozilla/bugs/bug53690-1.html has never worked
WebKit Review Bot
Reported
2011-09-07 16:26:56 PDT
tables/mozilla/bugs/
bug53690
-1.html has never worked Requested by abarth on #webkit.
Attachments
Patch
(8.71 KB, patch)
2011-09-08 00:19 PDT
,
Adam Barth
no flags
Details
Formatted Diff
Diff
Patch
(3.58 KB, patch)
2011-10-14 01:41 PDT
,
Adam Barth
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Adam Barth
Comment 1
2011-09-08 00:19:17 PDT
Created
attachment 106705
[details]
Patch
Eric Seidel (no email)
Comment 2
2011-09-08 08:10:57 PDT
Comment on
attachment 106705
[details]
Patch Yay!
mitz
Comment 3
2011-09-08 11:49:37 PDT
I am not sure it’s a good idea to remove this test. It is not easy to see how it is redundant.
Eric Seidel (no email)
Comment 4
2011-09-08 11:54:09 PDT
The test appears broken, all it was doing is printing this: CONSOLE MESSAGE: line 4: Uncaught TypeError: Cannot read property 'action' of undefined I don't think the test's intention was to document that document.forms[1] returns unsigned when there is only one form on the page. :)
Eric Seidel (no email)
Comment 5
2011-09-08 11:59:11 PDT
The original bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=53690
Original test:
https://bug53690.bugzilla.mozilla.org/attachment.cgi?id=15971
The bug seems to be about table reflow. It's possible the test should just be modified to remove the action= part of the change, since all it seems to want to test is the document.write behavior. The test was noticed because Chromium "fails" the test due to differnet v8 messages (a long trail of tears). Adam removed it, seeking to remove always-broken tests.
mitz
Comment 6
2011-09-08 12:02:48 PDT
(In reply to
comment #4
)
> The test appears broken, all it was doing is printing this: > CONSOLE MESSAGE: line 4: Uncaught TypeError: Cannot read property 'action' of undefined
Looking at platform/mac/tables/mozilla/bugs, I see that the test was producing a render tree dump and a pixel result.
> I don't think the test's intention was to document that document.forms[1] returns unsigned when there is only one form on the page. :)
Agreed. (In reply to
comment #5
) > The test was noticed because Chromium "fails" the test due to differnet v8 messages (a long trail of tears). Seems like a great test! We should have more test that uncover quirks and other problems, not fewer.
Eric Seidel (no email)
Comment 7
2011-09-08 12:04:12 PDT
(In reply to
comment #6
)
> (In reply to
comment #5
) > > The test was noticed because Chromium "fails" the test due to differnet v8 messages (a long trail of tears). > > Seems like a great test! We should have more test that uncover quirks and other problems, not fewer.
This is a well documented "quirk". :) If that were the only thing this test provided, it would not be a very good test for such. :)
Adam Barth
Comment 8
2011-09-08 12:06:21 PDT
> Seems like a great test! We should have more test that uncover quirks and other problems, not fewer.
Fortunately (or unfortunately) we have lots of test coverage for that particular issue. :)
Adam Barth
Comment 9
2011-09-08 12:07:45 PDT
> It's possible the test should just be modified to remove the action= part of the change, since all it seems to want to test is the document.write behavior.
Unfortunately, the document.write was never happening because the JavaScript threw an exception before it executed the write. We can change the test to do something else, but this test has never been testing anything, as far as I can tell.
mitz
Comment 10
2011-09-08 12:15:56 PDT
(In reply to
comment #9
)
> this test has never been testing anything, as far as I can tell.
I have a render tree dump and an image saying otherwise.
Adam Barth
Comment 11
2011-09-08 12:19:49 PDT
(In reply to
comment #10
)
> (In reply to
comment #9
) > > this test has never been testing anything, as far as I can tell. > > I have a render tree dump and an image saying otherwise.
Can you explain what this test is testing?
mitz
Comment 12
2011-09-08 12:33:36 PDT
(In reply to
comment #11
)
> (In reply to
comment #10
) > > (In reply to
comment #9
) > > > this test has never been testing anything, as far as I can tell. > > > > I have a render tree dump and an image saying otherwise. > > Can you explain what this test is testing?
It is testing (primarily table-) layout and rendering code.
Adam Barth
Comment 13
2011-09-08 13:47:24 PDT
> It is testing (primarily table-) layout and rendering code.
Ok. If you're not interested in actually engaging in this discussion, we can leave this test in its useless state.
mitz
Comment 14
2011-09-08 14:10:56 PDT
(In reply to
comment #13
)
> > It is testing (primarily table-) layout and rendering code. > > Ok. If you're not interested in actually engaging in this discussion, we can leave this test in its useless state.
While I’ll be happy with that result (leaving the test in its current state, which is not useless), I am sorry that you think that I am not interested in discussing this. Let me try again: detecting changes in behavior, which are possibly bugs, is one of the main reasons we have regression tests. Running the tests after making a code change often reveals an unanticipated, undesirable effect of the change on one ore more tests. It is not easy to determine that any unique test is redundant, in the sense that removing it will not allow an undesirable code change to sneak in; so in principle, the argument for removing a test should be more compelling than that it is not immediately obvious how a code change could cause it to fail without affecting any one of the remaining tests.
Adam Barth
Comment 15
2011-09-08 14:24:49 PDT
I assume you'll agree that this test is not intended to test HTML parsing. We have lots of test coverage for how the parser works in these situations. That means the important aspect is the DOM, which is the following: html body table tbody tr td table border=1 tbody tr td script td "x" which is almost identical to tables/mozilla/bugs/
bug53690
-2.html and a number of other table tests. The unique thing that this test was trying test was the interaction of document.writing a form in the middle of this process. However, because that was never happening, this test wasn't actually testing anything different than many other tests.
mitz
Comment 16
2011-09-08 15:33:05 PDT
Can this be resolved by removing the content of the script element in this test?
Adam Barth
Comment 17
2011-09-08 15:48:24 PDT
Comment on
attachment 106705
[details]
Patch Sure. Thanks.
Adam Barth
Comment 18
2011-10-14 01:41:03 PDT
Created
attachment 110980
[details]
Patch
Eric Seidel (no email)
Comment 19
2011-10-14 01:42:39 PDT
Comment on
attachment 110980
[details]
Patch SGTM.
WebKit Review Bot
Comment 20
2011-10-14 03:22:55 PDT
Comment on
attachment 110980
[details]
Patch Clearing flags on attachment: 110980 Committed
r97459
: <
http://trac.webkit.org/changeset/97459
>
WebKit Review Bot
Comment 21
2011-10-14 03:23:00 PDT
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug