1449383 - With "Facebook Container" extension, some shift-clicked external links *open in Facebook's container*, & crash if you drag them off, in mozilla::dom::TabChild::RecvSwappedWithOtherRemoteLoader: MOZ_CRASH("Update to TabContext after swap was denied.")

Status: RESOLVED WORKSFORME

(Core :: DOM: Content Processes, defect, P3)

Description

[Daniel Holbert [:dholbert]]

STR:
 1. Install the "Facebook Container" add-on:
  https://addons.mozilla.org/en-US/firefox/addon/facebook-container/
 2. Visit https://www.facebook.com/ and log in.
 3. Right click on your facebook tab and choose "Pin Tab".
 4. In that pinned tab, visit e.g. https://www.facebook.com/mozilla/posts/10156136938527381 (or just scroll down your feed to find a post an external link)
 5. Shift+Click the external link (the "blog.mozilla.com" link in the post above; either the link-text or the "tile", doesn't matter).

 ---> A new window opens with a tab at the external site.

 6. Ctrl+T in that new window to open a second tab.
 7. Now drag the blog.mozilla.com tab off of that window.

EXPECTED RESULTS:
 - After step 5, the new window (from shift-click) should be a normal tab.
 - No crash.

ACTUAL RESULTS:
 - After step 5: the blog.mozilla.com tab is in the Facebook container! (it has a blue underline and says "Facebook" at the right of the URL bar, despite the fact that it's a non-Facebook site!)  This doesn't always happen, but it's happened in at least 50% of my attempts. If it doesn't happen for you, try repeating step 5. 

 - After step 7: the dragged-off tab and the pinned facebook tab both show "content process crashed" pages.


Sample crash report: bp-71f130a9-9670-4cc6-ac34-db6ee0180328


I'm not sure where this bug should go -- I'm guessing the "After step 5" vs. "After step 7" results might be two independent bugs, where the latter one only happens after we've triggered the first one. Not sure though.

Comment 1

[Daniel Holbert [:dholbert]]

A few updates:
 - You don't actually need the tab to be pinned. So you can skip step 3.
 - So far, I *think* this only seems to happen for links that shows "l.facebook.com/l.php?u=..." in the link-target-preview status-bubble when you hover it them.  (It's not entirely predictable which external links will show up this way, but typically one of the link-text or the "tile" or the text below the tile will show up that way, at https://www.facebook.com/mozilla/posts/10156136938527381 )  Note that links only seem to show up this way the first time you click them, and then Facebook immediately updates them, or something.

 - Also worth noting: I haven't been able to trigger this bug by *directly visiting* a l.facebook.com link. I can only trigger it by shift-clicking one on Facebook, in a pinned tab.

 - At the end of my STR, the facebook tab doesn't always seem to crash, but the dragged-off tab always does.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: screencast of bug

Comment 3

[Daniel Holbert [:dholbert]]

Looks like the crash (from crash report in comment 0) is:
> MOZ_CRASH(Update to TabContext after swap was denied.)

Also looks like we've had versions of this same issue previously: bug 1294237, bug 1280105.  CC'ing baku & mconley who were involved with fixing those bugs...

Comment 4

[Daniel Holbert [:dholbert]]

(baku, maybe you could take a first look here?)

Comment 5

[Marion Daly [:mdaly]]

Hi jim, Baku isn't available to work on this, can you find someone else to take a look?

Comment 6

[Liz Henry (:lizzard) (relman/hg->git project)]

Is this still reproducible in 62? I still see the crash signature at a fairly low volume.

Comment 7

[Daniel Holbert [:dholbert]]

Yes it is. I just triggered it now with Friday's Nightly (hadn't quite gotten today's yet when I tried to repro) -- here's the crash report:  bp-72a7988d-d6d3-486e-bbfd-b95f80180604

Comment 8

[Daniel Holbert [:dholbert]]

FWIW, this bug's STR got a bit worse a few days ago -- see bug 1475699. (Basically, we now get a blank new window, rather than a new window with the right content in the wrong container. bug 1475699 has the details.)

I suspect that once that regression has been addressed, this will go back to being broken in the same way that it was before; but it'd be worth retesting at that point to be sure.

Comment 9

[Marcia Knous [:marcia]]

Updating affected branches. Fairly low volume on all branches.

Comment 10

[Neha Kochar [:neha]]

Jim, could you please find someone to look into this?

Comment 11

[Jim Mathies [:jimm]]

This is pretty corner case so I really don't have anyone with the cycles for it right now.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.