| Summary: | Add SPI to access the WKNavigation from the navigation action and response | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | David Quesada <david_quesada> | ||||||
| Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> | ||||||
| Status: | RESOLVED WONTFIX | ||||||||
| Severity: | Normal | CC: | achristensen, beidson, cdumez, ggaren, sam, webkit-bug-importer | ||||||
| Priority: | P2 | Keywords: | InRadar | ||||||
| Version: | WebKit Nightly Build | ||||||||
| Hardware: | Unspecified | ||||||||
| OS: | Unspecified | ||||||||
| Attachments: |
|
||||||||
|
Description
David Quesada
2019-03-27 00:00:39 PDT
Created attachment 366059 [details]
Patch
Created attachment 366076 [details]
Patch v2
Try to fix the GTK and WPE builds
This seems odd to me. WKNavigation is supposed to represent, and is publicly document as such, the navigation of a "webpage", which maps to main-frame navigations. I'm not sure exposing, even as SPI, navigation objects for subframes makes all that much sense. Comment on attachment 366076 [details] Patch v2 View in context: https://bugs.webkit.org/attachment.cgi?id=366076&action=review > Source/WebKit/ChangeLog:9 > + Given a WKNavigationAction or a WKNavigationResponse, it should be possible to determine Sam is right that WKNavigation is supposed to represent a page (aka main frame) navigation so exposing it for subframes seems odd. I think you could achieve your stated goal by giving WKNavigationAction a property indicating whether it has the download attribute, and giving WKNavigationResponse a pointer to WKNavigationAction. That would avoid introducing a WKNavigation object for things that are not main frame navigations. Comment on attachment 366076 [details]
Patch v2
After talking about this a bit more, Alex and I came up with another solution.
|