Summary: | Committed URL is not reset when a new load starts | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Carlos Garcia Campos <cgarcia> | ||||
Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> | ||||
Status: | RESOLVED INVALID | ||||||
Severity: | Normal | CC: | andersca, ap, thorton | ||||
Priority: | P2 | ||||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | Unspecified | ||||||
OS: | Unspecified | ||||||
Attachments: |
|
Description
Carlos Garcia Campos
2014-09-04 03:37:02 PDT
Created attachment 237616 [details]
Patch
I've rewritten the unit tests to use a test class and make easier to add more test cases.
Comment on attachment 237616 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=237616&action=review > Source/WebKit2/ChangeLog:8 > + Reset the committed URL when a new load starts. I don't see how this can be right. When a load hasn't been committed yet, the current page is unchanged - this is the very reason for having an uncommitted state. If the user starts a load and immediately hits Esc to cancel, the page should remain in the same state that it was before load. (In reply to comment #2) > (From update of attachment 237616 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=237616&action=review > > > Source/WebKit2/ChangeLog:8 > > + Reset the committed URL when a new load starts. > > I don't see how this can be right. When a load hasn't been committed yet, the current page is unchanged - this is the very reason for having an uncommitted state. If the user starts a load and immediately hits Esc to cancel, the page should remain in the same state that it was before load. I see your point, and I agree that's the last committed URL in the page/frame, but I'm not so sure that's the active URL. I guess we need to define what the active URL is, though. This is what we have in the WebKitGTK+ API documentation: http://webkitgtk.org/reference/webkit2gtk/stable/WebKitWebView.html#webkit-web-view-get-uri It doesn't say anything about the active URL when the provisional load fails, what do you think it should be? I agree we should not reset the commited URL on new load, closing as invalid. |