Bug 27707 - [WML] History handling / page cache / loading is buggy and depends on several hacks
Summary: [WML] History handling / page cache / loading is buggy and depends on several...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nikolas Zimmermann
URL:
Keywords:
Depends on:
Blocks: 20393
  Show dependency treegraph
 
Reported: 2009-07-27 05:08 PDT by Nikolas Zimmermann
Modified: 2009-07-27 10:04 PDT (History)
1 user (show)

See Also:


Attachments
Initial patch (24.68 KB, patch)
2009-07-27 09:46 PDT, Nikolas Zimmermann
staikos: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nikolas Zimmermann 2009-07-27 05:08:19 PDT
As the summary says the whole WML loading / page cache / history handling is flawed.
It depends on several hacks in FrameLoader / WMLGoElement / WMLCardElement / WMLPageState.

* There should be no need to track the history length on our own
* <go> / <a> / <anchor> / <do> / <prev> shouldn't need to deal with the FrameLoader directly (currently setting setForceReloadWmlDeck()
* FrameLoader needs to detect WML documents and handle them approriate (always reload, no caching, etc.) The tricky part is detecting our layout tests which embed WML content in a XHTML document (which is really 'hacky', but needed for our automatic testing facilities).

Fixing these issues should stabilize the loading area between running the layout tests standalone in DRT and using WML docs directly.
Uploading a patch with new testcases soon.
Comment 1 Nikolas Zimmermann 2009-07-27 09:46:27 PDT
Created attachment 33553 [details]
Initial patch
Comment 2 Nikolas Zimmermann 2009-07-27 10:04:53 PDT
Landed in r46418.