Closed Bug 1226432 Opened 9 years ago Closed 8 years ago

Add a synchronous version of RemoteOpenFile

Categories

(Core :: Networking: JAR, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: jduell.mcbugs, Unassigned)

References

Details

Attachments

(1 file)

Attached file irc chat with fabrice
So certain loads of CSS require synchronous Open(), and they're failing in e10s because our hack-y RemoteOpenFile implementation doesn't provide it.  (See the attached IRC chat and bug 1179536 for details)

It looks like the fastest path to a fix for now at least is to implement a version of RemoteOpenFile that does the "send IPDL to parent, open fd, and return it to child" synchronously.

This will require at a minimum a new IPDL protocol.  The existing PRemoteOpenFile.ipdl uses the constructor & destructor to request/receive the fd, but that's async.  So instead we'll need a regular constructor/destructor, and a sync RemoteOpen() method that returns an fd.

I suspect we'll want to move all the nsIFile functions and any other shared logic from RemoteOpenFileChild to a new base class that both RemoteOpenFileChild and RemoteSyncOpenFileChild inherit from, so we don't have to duplicate all that logic.

RemoteOpenFileChild currently calls into TabChild::GetCachedFileDescriptor() to see if the fd is already cached at that layer.  We could either change that API to a synchronous one instead of a listener (AFAICT remoteOpen is the only user of the API), or we could probably just skip checking the Tabchild (the tabchild cache is only used when LoadURI is called, which is for top-level loads, which we don't care about here).
Fabrice: can you give us a test case that shows where this is failing today?  That would be handy for knowing whether we've fixed this (and ideally we won't have to write a new test).
Flags: needinfo?(fabrice)
(In reply to Jason Duell [:jduell] (needinfo? me) from comment #1)
> Fabrice: can you give us a test case that shows where this is failing today?
> That would be handy for knowing whether we've fixed this (and ideally we
> won't have to write a new test).

Not really, because that fails only when we do an open() as the first request in a jar. Once the jar is cached things "work". Until we get a memory pressure event, and flush the cache, and that happens on b2g.
Flags: needinfo?(fabrice)
No big deal: we'll just use one of the existing libjar xpcshell tests in e10s mode to test this code.
Whiteboard: [necko-would-take]
This feature was just for the app:// protocol, which is now toast.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Whiteboard: [necko-would-take]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: