[Webkit-unassigned] [Bug 83959] [chromium] Add ability to override user agent string per-WebFrameClient
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Apr 27 17:34:27 PDT 2012
https://bugs.webkit.org/show_bug.cgi?id=83959
--- Comment #11 from dfalcantara at chromium.org 2012-04-27 17:34:26 PST ---
(In reply to comment #10)
> I suspect if we were able to add this feature to WebCore proper, other platforms would start using it. It's unfortunate that everyone has to reimplement the same code. I'm not saying you have to do this. It could be left as a future cleanup.
I agree. I was going to suggest opening a different bug to track it, but I wasn't clear on how the process works in the WebKit repo.
> Does the affect of the checkbox last for the entire duration of the tab or does it uncheck when you navigate to a different domain (e.g., by clicking a link)?
The effect of the checkbox carries over from previous navigations on the same tab: if it's on for one page and the user clicks a link, the flag stays on. When the user goes backwards or forwards in their history, the flag tracks what UA was used to load the page when they were last on the page and re-sets it accordingly. This helps avoid issues with saved zoom levels and scroll positions when the user reloads a page with a different UA than it is expecting.
> Hooking into NavigationEntry seems like a more invasive change than just setting a bool on WebFrame or WebFrameClient (if that'll meet your use case). I'm not that worried about the memory, just the complexity of changing NavigationEntry.
Yeah, I understand. I'm definitely open to suggestions for cleaner ways to satisfy the requirements...
> If we're going to do a callback to WebFrameClient, we may be able to remove Platform::userAgent from Platform.h and roll that into the chrome side code directly.
That makes sense. We'd be able to pull it out of webkit_glue, if I'm understanding the implications correctly.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list