| Summary: | Add getter for FrameLoader::m_suppressOpenerInNewFrame | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Nate Chapin <japhet> | ||||||
| Component: | WebCore Misc. | Assignee: | Nate Chapin <japhet> | ||||||
| Status: | RESOLVED FIXED | ||||||||
| Severity: | Normal | CC: | abarth, ap | ||||||
| Priority: | P2 | ||||||||
| Version: | 528+ (Nightly build) | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Attachments: |
|
||||||||
|
Description
Nate Chapin
2009-10-20 10:36:37 PDT
Created attachment 41512 [details]
patch
Comment on attachment 41512 [details]
patch
The ChangeLog does not explain why we need this getter. Why do we need it?
You're right, oops. Chromium is looking for a definitive way to determine whether a link was noreferrer and therefore is safe to open in a new process. If the opener is being suppressed, that should be a good indication (better than any heuristic) that an entirely new context is the correct decision. Ugg. The problem is that this isn't really a property of the FrameLoader but a property of the current FrameLoadTask (which is a concept that doesn't really exist at the moment). I guess it's ok to dig this hole a bit deeper... I'll try to remember not to review this getter even though it looks like dead code. If you post an updated patch with a better ChangeLog, I can review it again. Created attachment 41515 [details]
added more descriptive changelog entry
Yeah, sorry to make the FrameLoader mess worse :-(
If you would like me to help at all with cleanup of FrameLoader, I think I'm now on the hook.
Comment on attachment 41515 [details]
added more descriptive changelog entry
Ok.
Thanks for offering to help with FrameLoader. The next step is somewhat involved (splitting out the document-specific processing), but there might be parallelizable tasks after that.
This was landed in http://trac.webkit.org/changeset/49872. |