Do you have an actual test case that demonstrates the issue? I mean I could of course try to create my own based on the steps you give, but if you already have done so, it would save me some time/make it easier to investigate...

Hmm, yeah, I can definitely reproduce this... let me see if I can figure out where things are failing...

(and I can only reproduce it with actual files from disk, with script-created File instances it works fine even without an extension)

Annoyingly enough it doesn't reproduce with M65 or M66, but I don't believe the bug is fixed there. A bisect points to https://chromium.googlesource.com/chromium/src/+/9022043fbc593f52e0694f08de0a53368d994064 as the thing that "fixes" my test case, which unfortunately probably just means that my repro isn't good enough to test cases where the worker is out of process. That does seem to imply though that somehow the mojo serialization is what is failing, but not sure why that would be the case. I'll dig in deeper...

Ah yes, figured it out (after getting a decent repro, a debug build just fails with a DCHECK pointing exactly to what the problem is).

(and the problem is not so much about having a extension or not, but about having a content type or not)

https://chromium-review.googlesource.com/c/chromium/src/+/924338 should fix it.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/bb84d169288460af40536ebbe0303cb35f11a5a1

commit bb84d169288460af40536ebbe0303cb35f11a5a1
Author: Marijn Kruisselbrink <mek@chromium.org>
Date: Fri Feb 16 23:47:57 2018

Correctly serialize empty content_type for blobs.

A BlobDataHandle could not have a content_type set, but that should be
treated no different from an empty string, so serialize it as such.
Otherwise this will trigger validation failures causing weird behavior
when for example a blob without a content type is posted on a
MessagePort.

Bug:  813146 
Change-Id: I0a20a6b91391e9aa490a337b93c74f9ab4316e31
Reviewed-on: https://chromium-review.googlesource.com/924338
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#537462}
[modify] https://crrev.com/bb84d169288460af40536ebbe0303cb35f11a5a1/third_party/WebKit/Source/platform/blob/SerializedBlobStructTraits.h

Since the fix here is so straight-forward I believe it should be safe to merge to M65 without canary coverage.

This bug requires manual review: We are only 13 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Approving merge to M65 branch 3325 based on comment #10 and per offline chat with mek@. Please merge ASAP. Thank you.

Internal bug for this is b/73257471.

+abdulsyed@ for M64 merge review as this is M64 regression.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e2d305c4e4e654e912f40156ad209277363482df

commit e2d305c4e4e654e912f40156ad209277363482df
Author: Marijn Kruisselbrink <mek@chromium.org>
Date: Tue Feb 20 23:27:49 2018

Correctly serialize empty content_type for blobs.

A BlobDataHandle could not have a content_type set, but that should be
treated no different from an empty string, so serialize it as such.
Otherwise this will trigger validation failures causing weird behavior
when for example a blob without a content type is posted on a
MessagePort.

TBR=mek@chromium.org

(cherry picked from commit bb84d169288460af40536ebbe0303cb35f11a5a1)

Bug:  813146 
Change-Id: I0a20a6b91391e9aa490a337b93c74f9ab4316e31
Reviewed-on: https://chromium-review.googlesource.com/924338
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#537462}
Reviewed-on: https://chromium-review.googlesource.com/927709
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#520}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/e2d305c4e4e654e912f40156ad209277363482df/third_party/WebKit/Source/core/messaging/BlinkCloneableMessageStructTraits.cpp

mek@, thank you for quick merge. Pls verify the bug with tomorrow's canary and beta version 65.0.3325.88 or higher.

Confirmed that the issue is fixed in 65.0.3325.73.

Thanks!

65.0.3325.73 doesn't include this fix. If it is working there, do we really need a merge listed at #13?

As mentioned in comment 5, in M65 and M66 it is harder to reproduce the issue since it will only occur when the worker and document are in different renderer processes (which if you're only testing with one document is unlikely to happen). So probably whatever steps were used to try to verify didn't take that into account.

Can confirm #18 for Chrome 65.0.3325.73. PostMessaging a file to the SharedWorker from another tab fails.

As there is no test case available in above comments, it will not be possible to verify this issue from TE-End. 

@mek: Could you please provide sample test case to check this issue from TE end.

Thanks!

The NextAction date has arrived: 2018-02-21

Confirmed the fix on 65.0.3325.88 - tested a primary and secondary tab connecting to the same SharedWorker. File objects without content-type in postMessages are received in the SharedWorker.

Also repeated the steps above to confirm breakage in 64.0.3282.167.