WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
58990
REGRESSION (
r84306
-
r84311
?): editing/undo/undo-iframe-location-change.html sometimes fails on SnowLeopard Intel Release (WebKit2 Tests)
https://bugs.webkit.org/show_bug.cgi?id=58990
Summary
REGRESSION (r84306-r84311?): editing/undo/undo-iframe-location-change.html so...
Jessie Berlin
Reported
2011-04-20 07:27:50 PDT
http://trac.webkit.org/changeset/84307
http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(WebKit2%20Tests)/r84306%20(10865)/results.html
http://build.webkit.org/results/SnowLeopard%20Intel%20Release%20(WebKit2%20Tests)/r84311%20(10866)/results.html
In addition, I am not really sure why the pixel test results for compositing/iframes/invisible-iframe.html and compositing/iframes/invisible-nested-iframe-hide.html are in the cross-platform directory. I would expect those tests to be failing when run with -p on a bunch of platforms.
Attachments
Add attachment
proposed patch, testcase, etc.
Ryosuke Niwa
Comment 1
2011-04-20 08:55:17 PDT
Enrica and I investigated the failure of editing/undo/undo-iframe-location-change.html but it passes locally.
Jessie Berlin
Comment 2
2011-04-22 08:08:03 PDT
(In reply to
comment #1
)
> Enrica and I investigated the failure of editing/undo/undo-iframe-location-change.html but it passes locally.
Just to be sure, you tested with WK2? I ask because it is failing pretty consistently on the SL WK2 bots. Did you get a chance to look into the compositing/iframes/invisible-nested-iframe-show.html failures?
Enrica Casucci
Comment 3
2011-04-22 11:58:35 PDT
I just tested one more time with
r84650
on my SnowLeopard machine and I see no failures in the editing tests.
Ryosuke Niwa
Comment 4
2011-04-22 12:36:24 PDT
(In reply to
comment #2
)
> (In reply to
comment #1
) > > Enrica and I investigated the failure of editing/undo/undo-iframe-location-change.html but it passes locally. > > Just to be sure, you tested with WK2? I ask because it is failing pretty consistently on the SL WK2 bots.
Yes.
> Did you get a chance to look into the compositing/iframes/invisible-nested-iframe-show.html failures?
No.
Jessie Berlin
Comment 5
2011-04-25 09:40:42 PDT
Because these are keeping the SL WK2 bots red, I am going to commit failing expected results soon.
WebKit Review Bot
Comment 6
2011-04-25 10:26:31 PDT
http://trac.webkit.org/changeset/84783
might have broken Chromium Win Release
Jessie Berlin
Comment 7
2011-04-25 14:19:45 PDT
Now I am really confused. As soon as I committed the expected failing results in
http://trac.webkit.org/changeset/84783
, the editing test started passing on the bots (which is now making the bots red again because it is expecting failure). Any ideas as to what happened here?
Adam Roben (:aroben)
Comment 8
2011-04-30 04:36:30 PDT
(In reply to
comment #7
)
> Now I am really confused. As soon as I committed the expected failing results in
http://trac.webkit.org/changeset/84783
, the editing test started passing on the bots (which is now making the bots red again because it is expecting failure). > > Any ideas as to what happened here?
I guess the bots must have gone back to their previous behavior, because they aren't red anymore.
Adam Roben (:aroben)
Comment 9
2011-04-30 04:41:06 PDT
These two tests seem unlikely to be failing for the same reason. I split out compositing/iframes/invisible-nested-iframe-show.html into a new bug:
bug 59864
.
Adam Roben (:aroben)
Comment 10
2011-04-30 04:42:26 PDT
(In reply to
comment #8
)
> (In reply to
comment #7
) > > Now I am really confused. As soon as I committed the expected failing results in
http://trac.webkit.org/changeset/84783
, the editing test started passing on the bots (which is now making the bots red again because it is expecting failure). > > > > Any ideas as to what happened here? > > I guess the bots must have gone back to their previous behavior, because they aren't red anymore.
My mistake, this test is indeed failing on the bots (because it's producing successful results, but we have failure results checked in). I guess we should just remove the expected failure results and see if it starts failing again.
Adam Roben (:aroben)
Comment 11
2011-04-30 04:48:29 PDT
Looks like this test is flaky:
http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28WebKit2%20Tests%29/builds/11238
did fail
http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28WebKit2%20Tests%29/builds/11237
did not fail
http://build.webkit.org/builders/SnowLeopard%20Intel%20Release%20%28WebKit2%20Tests%29/builds/11235
did fail
Adam Roben (:aroben)
Comment 12
2011-04-30 05:03:07 PDT
Added to the mac-wk2 Skipped file in
r85397
.
Adam Roben (:aroben)
Comment 13
2011-04-30 05:07:05 PDT
<
rdar://problem/9363346
>
Ryosuke Niwa
Comment 14
2011-04-30 09:49:21 PDT
There might be some race condition going on here. Maybe when a page navigates in WebProcess, undo stack isn't cleared immediately in UIProcess.
Eric Seidel (no email)
Comment 15
2011-04-30 09:50:29 PDT
See also
bug 20366
.
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