[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 16:22:15 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=83959





--- Comment #10 from Tony Chang <tony at chromium.org>  2012-04-27 16:22:15 PST ---
(In reply to comment #9)
> (In reply to comment #8)
> > The inspector hook is in FrameLoader::userAgent (calls into InspectorInstrumentation::applyUserAgentOverride).  I think it would be nice if we could share some code with Inspector (e.g., the override code would live in WebCore and Inspector would call into this code), but not a requirement.  The benefit of sharing would be we wouldn't have to check twice for an override.
> 
> I agree that it'd be nice, but it seems that a couple of the other platforms also introduce their own override/custom user agents aside from the Inspector.

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.

> > Rather than keep track of the override in NavigationEntry, is it possible to set a bool on FrameLoaderClientImpl (by adding a method on WebFrame that you call when the menu is checked)?  That may use less memory and keep most of the code change in a single repository.
> 
> I don't think this will work with the way the feature is defined.  The flag doesn't change on a per-FrameLoaderClientImpl basis; different NavigationEntries can require the flag be set differently, depending on what the user wants it to be set as.  Since multiple NavigationEntries can share the same FrameLoaderClientImpl, we need to store it higher.

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)?

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.

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.

-- 
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