Closed Bug 1163560 Opened 9 years ago Closed 9 years ago

[e10s] Undo closed tab doesn't restore the correct state of a bug when using BMO's modal view

Categories

(Firefox :: Tabbed Browser, defect)

Product:
Firefox
Component:
Tabbed Browser
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
e10s m7+ ---

People

(Reporter: emorley, Unassigned)

References

Details

STR:
1) Navigate to an existing bug in modal view
2) Add a comment and press submit
3) Close tab
4) Use undo close tab

Expected:
Comment added in step #2 is visible in the restored tab.

Actual:
Restored tab has the same content as at step #1, and the comment added in #2 only appears after refreshing the page.

This does not happen when not using modal view.
I'm pretty sure this was the second bug I was hitting in bug 1161983, for which I couldn't remember the full STR.
that's rather odd; we don't do anything weird with caching.
Assignee: nobody → glob
comment 2 doubled as a test; the bug was correctly displayed after the tab closure was undone.
.. both with and without entering edit mode.

ed, does this happen without any firefox addons enabled?
Flags: needinfo?(emorley)
on irc ed proposed that this may be e10s related, and after a few tests that does appear to be the case.
Blocks: e10s
Component: User Interface: Modal → Tabbed Browser
Product: bugzilla.mozilla.org → Firefox
Summary: Undo closed tab doesn't restore the correct state of a bug when using modal view → [e10s] Undo closed tab doesn't restore the correct state of a bug when using BMO's modal view
Version: Production → unspecified
Assignee: glob → nobody
tracking-e10s: --- → ?
Flags: needinfo?(emorley)
Mike, do you think this could be related to some of the cache key work? Session restore also uses cache keys, maybe incorrectly in e10s.
Flags: needinfo?(mconley)
That could very well be the case. The patch for bug 1156493 landed on the 10th, so would have been in the May 11th Nightly, so it fits the timeline.

Could someone who is experiencing this try a build from this push:

https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=77d92f6d7679

And then a build from this push:

https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=371cbdcc9562

If you can only reproduce the problem in the second, I think we can squarely pin this on bug 1156493.
Flags: needinfo?(mconley) → needinfo?(emorley)
Test
Flags: needinfo?(emorley)
It repros on the earlier push (77d92f6d7679), which I guess makes sense, since I'm sure this has been happening for a while (I was just not able to narrow the STR until recently to file the bug). So I'm presuming this is unrelated to bug 1156493 then.
Hey Ed,

Hm... I think I was confused - I believe billm was wondering whether or not bug 1156493 _fixed_ this then. Can you try https://treeherder.mozilla.org/#/jobs?repo=mozilla-inbound&revision=371cbdcc9562 to see if the bug goes away?

Also, do you know how long this has been a problem?
tracking-e10s: ? → m7+
Flags: needinfo?(emorley)
I've since had to stop using e10s due to too many tab crashes, so I'll have to try a new profile at some point, but may not have time for a few days.
Flags: needinfo?(emorley)
emorley,

Bug 1163900 is on integration, which should (supposedly) make the content process far less crashy.

Once that's on Nightly, could you please re-enable e10s and see if you can still reproduce this?
Flags: needinfo?(emorley)
Test
Flags: needinfo?(emorley)
Appears to WFM now with https://hg.mozilla.org/mozilla-central/rev/127a78bac3f1
Thanks! :-)
Status: NEW → RESOLVED
Closed: 9 years ago
Depends on: 1156493
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.