Closed Bug 1306928 Opened 8 years ago Closed 7 years ago

Document cookie getter can be slow with e10s

Categories

(Core :: Networking: Cookies, defect)

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1331680
Tracking Status
firefox52 --- affected

People

(Reporter: bzbarsky, Unassigned)

References

Details

(Whiteboard: [necko-next])

My browser was just being laggy, and profiling showed that a bunch of time in the content process was spent waiting on condvars with this stack:

js::jit::DoCallNativeGetter(JSContext*, JS::Handle<JSFunction*>, JS::Handle<JSObject*>, JS::MutableHandle<JS::Value>)  (in XUL) + 110  [0x10ba3868e]
mozilla::dom::GenericBindingGetter(JSContext*, unsigned int, JS::Value*)  (in XUL) + 382  [0x109a2241e]
mozilla::dom::HTMLDocumentBinding::get_cookie(JSContext*, JS::Handle<JSObject*>, nsHTMLDocument*, JSJitGetterCallArgs)  (in XUL) + 163  [0x10997b363]
nsHTMLDocument::GetCookie(nsAString_internal&, mozilla::ErrorResult&)  (in XUL) + 292  [0x109cdd884]
mozilla::net::CookieServiceChild::GetCookieStringInternal(nsIURI*, nsIChannel*, char**, bool)  (in XUL) + 537  [0x107f9a959]
mozilla::net::PCookieServiceChild::SendGetCookieString(mozilla::ipc::URIParams const&, bool const&, bool const&, mozilla::NeckoOriginAttributes const&, nsCString*)  (in XUL) + 533  [0x1089a5415]
mozilla::ipc::MessageChannel::Send(IPC::Message*, IPC::Message*)  (in XUL) + 1899  [0x10840f49b]
PR_WaitCondVar  (in libnss3.dylib) + 255  [0x107c7a94f]

That's a web page doing document.cookie, which calls into the cookie service, which starts doing sync IPC to the parent process...

I thought we cached cookies in the child process, at least to some extent.  If we don't, can we?
Whiteboard: [necko-next]
(In reply to Boris Zbarsky [:bz] (still a bit busy) from comment #0)
> I thought we cached cookies in the child process, at least to some extent. 
> If we don't, can we?

With multiple processes, this gets complicated since we'd have to invalidate the cache in all child processes whenever we change the cookie for any given domain. We held off on doing this because of that complexity but I guess we could implement a cache if we needed to.
> this gets complicated since we'd have to invalidate the cache in all child processes

That's true.  Do we need to do it synchronously, or can we do it async?  I guess we'd more or less have to do it synchronously so you can log in in one window and then in another one navigate to the same site and seem logged in?  But the sync bit would only need to be the call to the parent; once the parent receives the updated value and sends out async cache updates to the other processes it seems like we would be fine.  That's not worse, performance-wise than our current setup where any cookie write _or_ read is a sync call to the parent, right?
Being addressed in Bug 1331680, specific plan in Bug 1331680 Comment 14.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.