Cache override lookup's for navigator.userAgent on the renderer side

Bug #1350914 reported by Chris Coulson on 2014-07-31
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Oxide
Medium
Chris Coulson

Bug Description

Currently, every access of navigator.userAgent results in a synchronous IPC request to the browser process where we call in to the WebContextDelegateWorker for the particular context if there is one, in order to lookup an override for the user agent string. This should really be cached on the renderer side so that we only do one call until the document URL changes

Changed in oxide:
importance: Undecided → Medium
status: New → Triaged
milestone: none → branch-1.3
Changed in oxide:
milestone: branch-1.3 → branch-1.4
Changed in oxide:
milestone: branch-1.4 → branch-1.5
Changed in oxide:
milestone: branch-1.5 → branch-1.6
Changed in oxide:
assignee: nobody → Chris Coulson (chrisccoulson)
Changed in oxide:
milestone: branch-1.6 → branch-1.7
Changed in oxide:
milestone: branch-1.7 → none
Chris Coulson (chrisccoulson) wrote :

This will sort-of be fixed by the implementation of bug 1410753, in that the data supplied to WebContext.userAgentOverrides will be serialized and shared with content processes. As the new WebContext.userAgentOverrides API will effectively deprecate the existing mechanism to override navigator.userAgent, it's not worth spending additional time fixing this specifically for the old mechanism.

Changed in oxide:
milestone: none → branch-1.9
status: Triaged → In Progress
Changed in oxide:
status: In Progress → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers