Closed Bug 572954 Opened 14 years ago Closed 14 years ago

Intermittent failure in browser_save_resend_postdata.js | TypeError: gBrowser.contentDocument.getElementById("postForm") is null

Categories

(Firefox :: File Handling, defect, P1)

Product:
Firefox
Component:
File Handling
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 4.0b1

People

(Reporter: philor, Assigned: dbaron)

References

Details

(Keywords: intermittent-failure) 

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1276828365.1276830369.9756.gz
Rev3 Fedora 12x64 mozilla-central debug test mochitest-other on 2010/06/17 19:32:45
s: talos-r3-fed64-028

TEST-START | chrome://mochikit/content/browser/toolkit/content/tests/browser/browser_save_resend_postdata.js
Chrome file doesn't exist: /home/cltbld/talos-slave/mozilla-central-fedora64-debug-u-mochitest-other/build/mochitest/browser/toolkit/content/tests/browser/head.js
JS Component Loader: WARNING chrome://mochikit/content/browser/toolkit/content/tests/browser/common/toolkitFunctions.js:48
                     octal literals and octal escape sequences are deprecated
JS Component Loader: WARNING chrome://mochikit/content/browser/toolkit/content/tests/browser/common/toolkitFunctions.js:48
                     octal literals and octal escape sequences are deprecated
JS Component Loader: WARNING chrome://mochikit/content/browser/toolkit/content/tests/browser/common/toolkitFunctions.js:48
                     octal literals and octal escape sequences are deprecated
WARNING: Positioned frame that does not handle positioned kids; looking further up the parent chain: file /builds/slave/mozilla-central-linux64-debug/build/layout/base/nsCSSFrameConstructor.cpp, line 5546
++DOCSHELL 0x47f1190 == 23
++DOMWINDOW == 145 (0x1187d98) [serial = 2359] [outer = (nil)]
WARNING: Positioned frame that does not handle positioned kids; looking further up the parent chain: file /builds/slave/mozilla-central-linux64-debug/build/layout/base/nsCSSFrameConstructor.cpp, line 5546
WARNING: Positioned frame that does not handle positioned kids; looking further up the parent chain: file /builds/slave/mozilla-central-linux64-debug/build/layout/base/nsCSSFrameConstructor.cpp, line 5546
++DOMWINDOW == 146 (0x49fd808) [serial = 2360] [outer = 0x1187d30]
WARNING: Positioned frame that does not handle positioned kids; looking further up the parent chain: file /builds/slave/mozilla-central-linux64-debug/build/layout/base/nsCSSFrameConstructor.cpp, line 5546
WARNING: Positioned frame that does not handle positioned kids; looking further up the parent chain: file /builds/slave/mozilla-central-linux64-debug/build/layout/base/nsCSSFrameConstructor.cpp, line 5546
WARNING: Positioned frame that does not handle positioned kids; looking further up the parent chain: file /builds/slave/mozilla-central-linux64-debug/build/layout/base/nsCSSFrameConstructor.cpp, line 5546
WARNING: Positioned frame that does not handle positioned kids; looking further up the parent chain: file /builds/slave/mozilla-central-linux64-debug/build/layout/base/nsCSSFrameConstructor.cpp, line 5546
TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/toolkit/content/tests/browser/browser_save_resend_postdata.js | TypeError: gBrowser.contentDocument.getElementById("postForm") is null
And the start of all this was http://hg.mozilla.org/mozilla-central/rev/172a93563b1e disabling the constantly-failing browser_keyevents_during_autoscrolling.js, two lines up in the makefile, which doesn't imply anything good about anything.
This test is failing on >50% of test runs now... what's up with it?
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1276882168.1276883300.20007.gz
Rev3 MacOSX Snow Leopard 10.6.2 mozilla-central opt test mochitest-other on 2010/06/18 10:29:28
This is something new and happens a lot.
######################################################################
   [ Not a TinderboxPushlog Robot Comment ]
######################################################################

I'm definitely in a hurry, the best I can do now is to provide a few
pointers related to my past experience. It's not the first time that
this and other tests fail intermittently with no apparent reason, and
the conclusion at the time was:

 * One of the tests running before these ones didn't do a proper clean up.



In fact, the first version of "browser_keyevents_during_autoscrolling.js"
caused "browser_save_resend_postdata.js" (formerly browser_bug471962.js)
to fail. A tentative patch fixed this issue with these lines:

http://hg.mozilla.org/mozilla-central/file/172a93563b1e/toolkit/content/tests/browser/browser_keyevents_during_autoscrolling.js#l107

  // cleaning-up
  gBrowser.addTab().linkedBrowser.stop();
  gBrowser.removeCurrentTab();


The fact is that I still don't know for sure why calling stop() on the
newly opened tab in the previous test worked. I casually asked why, in
bug 512100 comment 4, but got no response. Later, in another context
I heard about an "about:blank" load that may be interfering with the
requested load, I think Gavin or Boris may know more about this.

Maybe there's a better way to handle this, at the start of the test,
instead of relying on previous tests doing a proper cleanup, but
unfortunately I don't have a solution ready!

I have to go now!
Looks like the first changeset for which this happened was:
http://hg.mozilla.org/mozilla-central/rev/172a93563b1e
which disabled a different test in the same directory.
Yup, see (if you can find it), comment 7. We just need someone to land something that will catch the TypeError and dump something to identify whose window gBrowser is, since it's apparently not the window the test expects it to be.
(In reply to comment #142)
> I landed something that might help:
> http://hg.mozilla.org/mozilla-central/rev/2fe127f49fec

Well I did explicitly intend to backout that part of this as well, but if it fixes the Orange I'll be happy anyway, I have a theory but can't investigate where I am atm (at work; and shouldn't even be on Bugzilla). but I do intend to look into it more carefully once I am home.
(In reply to comment #143)
> (In reply to comment #142)
> > I landed something that might help:
> > http://hg.mozilla.org/mozilla-central/rev/2fe127f49fec
> 
> Well I did explicitly intend to backout that part of this as well, but if it
> fixes the Orange I'll be happy anyway, I have a theory but can't investigate
> where I am atm (at work; and shouldn't even be on Bugzilla). but I do intend to
> look into it more carefully once I am home.

You intended to revert that part of Neil's patch?  Why?



In any case, this bug now appears to be fixed.  As I wrote in bug 567950 comment 413 (but with some modifications so it makes sense on this bug):

(In reply to bug 567950 comment 412)
> Disabling this test just seems to have caused bug 572954; perhaps both of them
> are caused by some earlier test leaving things in a bad state?

So noticing this actually led me to what seems to have fixed bug 572954.  In
particular:

Bug 567950 started on May 24, probably when the tracemonkey merge containing a
patch, disabling a test in the same directory as these, landed on
mozilla-central:
http://hg.mozilla.org/mozilla-central/rev/890c0d2e45b3
http://hg.mozilla.org/mozilla-central/rev/a8c721b2f221

When Callek re-enabled that test on June 9:
http://hg.mozilla.org/mozilla-central/rev/31fbc861bcb9
he inadvertently(?) backed out enndeakin's change from May 18:
http://hg.mozilla.org/mozilla-central/rev/eb49e81b9f4d

When gavin disabled the test failing in bug 567950 on June 17:
https://hg.mozilla.org/mozilla-central/rev/172a93563b1e
it caused the test in which Callek backed out Neil's fix to start failing (bug 572954).  (That test was renamed on June 8 so that it falls after this one rather than  before, though:
http://hg.mozilla.org/mozilla-central/rev/99271495668e )

My patch today (June 19) fixed the error made on June 9:
http://hg.mozilla.org/mozilla-central/rev/2fe127f49fec
and seems to have fixed bug 572954.

There was also an unexplained change on June 14 (though there were a whole bunch of browser-chrome test changes that morning) that changed bug 567950 from Mac-only to cross-platform (though less frequent on Windows than on Mac and Linux).
Assignee: nobody → dbaron
Status: NEW → RESOLVED
Closed: 14 years ago
Priority: -- → P1
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a6
(In reply to comment #145)
> (In reply to comment #143)
> > (In reply to comment #142)
> > > I landed something that might help:
> > > http://hg.mozilla.org/mozilla-central/rev/2fe127f49fec
> > 
> > Well I did explicitly intend to backout that part of this as well, but if it
> > fixes the Orange I'll be happy anyway, I have a theory but can't investigate
> > where I am atm (at work; and shouldn't even be on Bugzilla). but I do intend to
> > look into it more carefully once I am home.
> 
> You intended to revert that part of Neil's patch?  Why?

Err, after re-reading the changelog for this file, I realize my mistake in this comment. Since kdiff3 was giving me odd and wrong merge results, I explicitly took the file-state before those two disables on the TM branch. Which in this case was wrong (as it was the state on TM branch), so no did not intend to remove his fix, (sorry for confusion all around)

> In any case, this bug now appears to be fixed.

GREAT!

>  As I wrote in bug 567950 [snip]

Great synopsis and thank you again.
Ignore the previous comment, it was a mistake.
Whiteboard: [orange]
You need to log in before you can comment on or make changes to this bug.