Summary: | QWebPage::acceptNavigationRequest type is not QWebPage::NavigationTypeReload when QWebPage::reload() is called | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Benjamin Meyer <ben> | ||||
Component: | Page Loading | Assignee: | Benjamin Meyer <ben> | ||||
Status: | RESOLVED INVALID | ||||||
Severity: | Normal | CC: | kent.hansen, manyoso, staikos, tonikitoo, zack | ||||
Priority: | P2 | Keywords: | Qt | ||||
Version: | 528+ (Nightly build) | ||||||
Hardware: | PC | ||||||
OS: | OS X 10.5 | ||||||
Attachments: |
|
Description
Benjamin Meyer
2009-03-01 20:58:12 PST
Created attachment 28183 [details]
Fix with test
This looks correct in principle to me although I wonder if it'll cause a behavior change in Safari. Would feel better if Darin or someone more familiar with loader could look at it. After talking with ap and anttik on IRC we agreed the patch should be amended to use NavigationType instead of FrameLoadType enum in the NavigationAction ctor. Also, you should amend the in-code comment to explain what is happening and why. Finally, can you give a real world case where an application would need to be able to distinguish between Reload and Other for purposes of deciding the navigation policy as this might have unintended consequences for other API's and their clients. (e.g. why the Qt port needs to distinguish this) Any plans to proceed with this patch? I want to say I wrote this patch when trying to implement the reload and shift-reload feature for arora. === Bulk closing of Qt bugs === If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it. If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines. |