Closed Bug 1075302 Opened 5 years ago Closed 5 years ago

IndexedDB PBackground bug 994190 broke xhr.send() POSTing of IndexeDB-backed File/Blobs (or composite Blobs that include them)

Categories

(Core :: Storage: IndexedDB, defect)

x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla35

People

(Reporter: asuth, Assigned: bent.mozilla)

References

Details

Attachments

(2 files, 1 obsolete file)

Gaia email backend tests went red on sending ActiveSync emails where we XHR POST a composite Blob partially consisting of IndexeDB-backed File instances.  b2g-desktop bisection suspectd bug 994190 because the build before was fine but the build after was broken.

I've modified the existing test_blob_simple.html IndexedDB mochitest to reproduce this failure.  With custom-built firefox builds, the mochitest passes on the commit immediately prior to the landing of bug 994190 and fails on its landing in bug 994190 comment 21.

In the gaia email test we see a HTTP connection opened to our httpd.js server and then closed without any payload transmitted and this is easily visible with wireshark.  In the mochitest the network ramifications are less obvious since existing connections are open to the mochitest server.  However, we do get this handy test error output:

36 INFO Send blob to a worker, use it in an XHR POST without error
###!!! [Parent][OnMaybeDequeueOne] Error: Channel closing: too late to send/recv, messages will be lost
37 INFO TEST-UNEXPECTED-FAIL | /tests/dom/indexedDB/test/test_blob_simple.html | XHR generated the expected 404 - got error, expected 404
38 INFO Store a blob back in the database, and keep holding on to the blob, verifying that it still can be read.
###!!! [Parent][OnMaybeDequeueOne] Error: Channel closing: too late to send/recv, messages will be lost
39 INFO Got blob from database


Note that the choice of causing a 404 is simply because we don't care what the payload is and I have no idea what the mochitest server semantics are.
It'd be good to have tests for ActiveSync!

But of course we should fix this bug before that.
This is nasty, but XHR/Necko expect to be able to do main-thread I/O. That worked before (ugh) but remote blobs don't allow it. This patch relaxes that restriction a little.
Assignee: nobody → bent.mozilla
Attachment #8497936 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8500608 - Flags: review?(khuey)
Comment on attachment 8500608 [details] [diff] [review]
Allow some main-thread I/O to make necko happy, v1

Review of attachment 8500608 [details] [diff] [review]:
-----------------------------------------------------------------

yuck
Attachment #8500608 - Flags: review?(khuey) → review+
Attached patch Fix for e10s, v1Splinter Review
Applies on top of previous patch.
Attachment #8501212 - Flags: review?(khuey)
Flags: needinfo?(bent.mozilla)
https://hg.mozilla.org/mozilla-central/rev/97febbb46ef4
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
Hi Dylan, this feature apparently broke even though TBPL remained completely green. Can you find resources to get integration tests added for ActiveSync so that we don't break you again?
Flags: needinfo?(doliver)
The new test coverage added on this bug should cover the ActiveSync use-case going forward, but these are the bugs for getting e-mail coverage up on treeherder:
- Bug 975588 covers front-end integration tests
- Bug 1086906 (new) covers running the back-end integration tests as part of TBPL/treeherder.  (The only thing these tests do not cover is inter-app Blob sharing stuff.)  These tests already run on Travis, so it's mainly a question of the logistical issues to get these run and reported on our infra.
asuth is on the case, clearing my ni here
Flags: needinfo?(doliver)
You need to log in before you can comment on or make changes to this bug.