ASSERT(!m_frame || applicationCacheHost());
This assertion is clearly incorrect, because applicationCacheHost() returns null if m_frame is null. So, it effectively asserts that applicationCacheHost() is not null. This also isn't the case in attached test case.
Created attachment 46886 [details]
test case (will assert)
I don't really understand what ApplicationCacheHost is, so it's not quite clear to me whether it's ok to just remove this assertion, or whether null host should prevent DOMApplicationCache construction.
I'll take a look.
The intent of the assertion is to gaurantee that if there is a frame, there must be an applicationCacheHost. This is recognizing 'frameless' construction is a valid thing to do (i don't know what the use case is for that, but Alexey insisted that these should be constructable w/o a frame at some point).
DOMApplicationCache.m_frame == NULL when i run the test case in chrome (and chrome's test_shell). So no assertions. There may be recent changes that haven't rolled into view yet for chrome?
> Alexey insisted that these should be constructable w/o a frame at some point
I could have been wrong! I still think that this would be a reasonable behavior, but there's a lot of code in WebCore that doesn't work in frameless documents.
Do other constructors work in detached frames? What about window.history, or window.statusbar?
> DOMApplicationCache.m_frame == NULL when i run the test case in chrome
Re-checked with r53418, still getting a non-null detached frame here.
All detached frames or just about:blanks?
What is the expected behavior in a 'detached' frame anyway... are timers and xhrs and subresource loads expected to function properly?
After chatting with alexey, decided to remove this assertion. Its there to test my assumption that if we have a frame, it must have a documentLoader, which is not always the case (apparently).
I'll put together a patch soon'ish.
Also realized that we have to look at detached frame handling a little more closely throughout the scriptable objects dangling off of window properties.
Created attachment 47065 [details]
Comment on attachment 47065 [details]
> No new functionality, no new tests.
r=me, assuming you'll land the test simultaneously (be sure to make it dumpAsText).
Created attachment 47079 [details]
Now with a layout test to verify that the assertion has been removed.
Comment on attachment 47079 [details]
This test doesn't need waitUntilDone/notifyDone - it runs from onload, and doesn't use setTimeout.
Created attachment 47082 [details]
Now without waitUntilDone/notifyDone, and with closing tags and a blank line.
Comment on attachment 47082 [details]
Clearing flags on attachment: 47082
Committed r53596: <http://trac.webkit.org/changeset/53596>
All reviewed patches have been landed. Closing bug.