[Webkit-unassigned] [Bug 15765] ASSERTION FAILED: m_frame->page() in FrameLoader::tokenizerProcessedData using the new GMail interface

[bugzilla-daemon at webkit.org]

http://bugs.webkit.org/show_bug.cgi?id=15765





------- Comment #16 from freyther at handhelds.org  2008-01-03 06:53 PDT -------
(In reply to comment #15)
> (In reply to comment #14)
> > The test case seems to the influence the ones running after this one. How can
> > this be? Can I reset/restart the DRT somehow? How are these situations handled?
> 
> The "./WebKitTools/Scripts/run-webkit-tests --help" command will give you lots
> of options for running DRT.  The "-1" option will run each test with its own
> copy of DRT.  If this fixes the issue, a change to DRT may be required to reset
> whatever internal state that the test is changing in DRT or WebKit.  Or it may
> point to a bug in your patch.
> 

It is not my patch and not my test. .Running
"/WebKitTools/Scripts/run-webkit-tests -1 http/tests/loading" results in three
failing tests. Somehow the "frame "f1" - willCloseFrame" gets lost in some test
cases. Weird enough there is no such named frame in the failing test cases. So
this result is triggered by a previous test case (e.g. due a
FrameLoader::checkCallImplicitClose).

I think we have the following options:
   -Add my fix+test case and adjust the next failing test case (I get f1 closed
not the test after this one)
   -Run DRT singly on http/tests/loading and update the results.
   -Fix the root cause (always the best). I think when starting to load the new
test all active frames get closed. What DRT could do, or LayoutController on
the old test is to call FrameLoader::checkCallImplicitClose. This way we could
avoid the issue. There might be other things surviving from one test to another
but we don't see them yet.


-- 
Configure bugmail: http://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.