Closed Bug 1729545 Opened 11 months ago Closed 7 months ago

Sometimes back/forward navigation get stuck until page reload (F5)

Categories

(Core :: DOM: Navigation, defect, P2)

Desktop
Windows 10
defect

Tracking

()

VERIFIED FIXED
98 Branch
Tracking Status
firefox-esr78 --- disabled
firefox-esr91 --- disabled
firefox92 --- disabled
firefox98 --- fixed

People

(Reporter: alice0775, Assigned: smaug)

References

(Blocks 2 open bugs)

Details

(Keywords: nightly-community, Whiteboard: [fission])

Attachments

(4 files)

The problem appear if Fission is enabled.

Steps to reproduce:

  1. Enable Fission
  2. Open https://ftp.mozilla.org/pub/firefox/nightly/
  3. Open https://www.getginger.jp/ in the same tab
  4. Open https://ftp.mozilla.org/pub/firefox/nightly/ in the same tab
  5. Click the back button quickly and repeatedly until the first page is displayed.
    OR
    Press and hold Alt+← key until the first page is displayed.
  6. Click the forward button quickly and repeatedly until the last page is displayed.
    OR
    Press and hold Alt+→ key until the first page is displayed.
  7. Repeat step 5 and step 6

Actual Results:
Sometimes, Page is blank and back/forward navigation get stuck.
Pressing F5 will load the page and display it correctly, then subsequent back/forward clicks will work.

Expected Results:
back/forward navigation should not get stuck.

This is not a recent regression. I can reproduce the issue Nightly87.0a1 if Fission is enabled.
However, when Fission is disabled, this problem does not seem to occur.

Keywords: regression

Olli, here is another back/forward navigation that is only reproducible in Fission.

Fission Milestone: --- → ?
Flags: needinfo?(bugs)
Summary: Sometimes back/forward navigation get stuck until page reload(F5) → Sometimes back/forward navigation get stuck until page reload (F5)
Whiteboard: fission-soft-blocker
See Also: → 1728842
Duplicate of this bug: 1729532

I think I've run into basically the same bug, I also have fission enabled in Nightly.

Status: NEW → RESOLVED
Closed: 11 months ago
Resolution: --- → FIXED

Closed accidentally it seems.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Assigning to Olli.

Tracking for Fission MVP. This bug sounds pretty bad.

@ Alice0775: thanks for the excellent bug report, as always! :)

Assignee: nobody → bugs
Severity: -- → S3
Fission Milestone: ? → MVP
Priority: -- → P2

(In reply to Alice0775 White from comment #7)

Regression window where the back/forward problem is first seen:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f9eaabcf04e04f2b92ff6aa692599c2eabe92bf0&tochange=573659457e9c755806b3503803c05f45871fbab7

Alice0775, thank you for the regression window!

In that case, this bug is a regression from bug 1668577.

Regressions: 1668577

Alice or Tom, do you have more hints how to reproduce this?
Like, should I open first a new tab (so that it loads about:newtab) before loading the first page, or should I ctrl+click that link so that
first page is https://ftp.mozilla.org/pub/firefox/nightly/?

I have tried to reproduce, in both ways, but not luck yet.
And I have waited for the page to load, and I have just triggered next load asap.

Flags: needinfo?(evilpies)
Flags: needinfo?(bugs)
Flags: needinfo?(alice0775)

Sorry for the lack of information.

1st page is https://www.mozilla.org/en-US/firefox/nightly/firstrun/
2nd https://ftp.mozilla.org/pub/firefox/nightly/
3rd https://www.getginger.jp/ in the same tab
4th https://ftp.mozilla.org/pub/firefox/nightly/

Screencast: https://youtu.be/8oX96Jn_d2g
00:10 the bug appears, forward button stops working
00:22 reload
00:25 forward button is working again

Flags: needinfo?(alice0775)
Depends on: 1730977

This bug still happens to me, but I don't have a good way of reproducing it.

Flags: needinfo?(evilpies)

Can you still reproduce this?
(I can't, but even after some fixes it was difficult to reproduce.)

Flags: needinfo?(alice0775)

Yes, I can reproduce the issue in Nightly95.0a1(20211004215121) Windows10 With STR comment #0 and comment #10.
Clicking back/forward button stops responding until reload.

Flags: needinfo?(alice0775)

I've actually never managed to reproduce that issue. I've seen the blank page issue, but bug 1730977 fixed that (at least for me) and then there was another issue which bug 1725680 fixed.

But ok, thanks, I'll keep trying to reproduce this.

Depends on: 1734858

No luck reproducing, but bug 1734858 might help here

Could you try tomorrow's Nightly?

Flags: needinfo?(alice0775)

In Nightly95.0a1(20211013212517),
I can still reproduce the issue if fission is enabled.

Flags: needinfo?(alice0775)

thanks for testing. I'll keep trying out to reproduce the issue.

I've also been trying to reproduce, but haven't managed to either.

I can still reproduce the issue in latest Nightly.

However,
That so far I have only been able to reproduce the problem with the combination on this site.
No other site combinations or similar reports by other users have been found.
Also, when this problem occurs, it is easy to recover by pressing F5.

Based on these, Mark this as WONTFIX.

Status: REOPENED → RESOLVED
Closed: 11 months ago10 months ago
Resolution: --- → WONTFIX

Maybe lets mark as incomplete instead given that it's not possible to reproduce for us. We could reopen if needed.

Resolution: WONTFIX → INCOMPLETE
Attached video 4yK1ELSVC7.mp4

I can easily reproduce this bug also with these sites (and maybe more):
https://www.t-online.de/
https://us.yahoo.com/

STR:

  1. Open a new tab
  2. Load https://www.t-online.de/ in the new tab
  3. Load https://us.yahoo.com/ in the same tab
  4. Load https://www.t-online.de/ again in the same tab
  5. Press and hold Alt+→ or Alt+← to get back or forward

Maybe the video will help?

Flags: needinfo?(peterv)

(In reply to kernp25 from comment #23)

I can also reproduce this in Nightly95.0a1 windows10.

:smaug, Could you please test if you can reproduce this with str in comment #23?

Flags: needinfo?(bugs)

Still can't reproduce this.

(In reply to kernp25 from comment #23)

  1. Press and hold Alt+→ or Alt+← to get back or forward

The video seems to start after navigating in history to the first load of https://www.t-online.de/ and then goes forward one step. Is that done holding Alt+→?

Flags: needinfo?(peterv)
Attached file Log

I did manage to reproduce it once, by furiously going back and forward. Olly: here's some logging, I removed some irrelevant things from it, but still have the full log. I was going back, ended up on www.t-online.de but the page was blank.

Comment on attachment 9246811 [details]
Log

This seems part of the problem:

[Child 278575: Main Thread]: D/SessionHistory ChildSHistory::Go(-1), current index = 1
[Child 278575: Main Thread]: D/SessionHistory ChildSHistory::GotoIndex(0, -1), epoch 1
[Parent 276848: Main Thread]: D/SessionHistory HistoryGo(-1->0) epoch 1/id 44
[Parent 276848: Main Thread]: D/nsSHistory LoadEntry(0, 0x4, 0)

[Child 278575: Main Thread]: D/SessionHistory ChildSHistory::Go(-1), current index = 1
[Child 278575: Main Thread]: D/SessionHistory ChildSHistory::GotoIndex(0, -1), epoch 2

[Parent 276848: Main Thread]: D/SessionHistory HistoryGo(-1->-1) epoch 2/id 44
[Parent 276848: Main Thread]: D/nsSHistory LoadEntry(-1, 0x4, 0)
[Parent 276848: Main Thread]: D/nsSHistory Index out of range
[Parent 276848: Main Thread]: D/SessionHistory Dropping HistoryGo - bad index or same epoch (not in same doc)

(In reply to Peter Van der Beken [:peterv] from comment #26)

Is that done holding Alt+→?

Yes! You need to press and hold the keys (and not release them), until you get to the last or first history entry (or when the bug happens).

I haven't managed to reproduce. Need to figure out from peterv's log.

Status: RESOLVED → REOPENED
Resolution: INCOMPLETE → ---

If anyone wants to try the guess fix:
https://treeherder.mozilla.org/logviewer?job_id=355777043&repo=try has the links to Windows build.
Click Show Job Info (if job info isn't already shown) and then top left iframe should have links to target.installer.exe and target.zip
Use either of those to test the patch.

Can you test the build and confirm, it is working now?

I have tested it and the bug does not seem to occur anymore.

Flags: needinfo?(alice0775)

I can reproduce the issue with str comment#0 and comment#23 in trybuild(20211022182331).
And cannot reproduce with non-fission.

Flags: needinfo?(alice0775)

(In reply to kernp25 from comment #34)

I have tested it and the bug does not seem to occur anymore.

I did not checked, that fission was not enabled. The bug still happens for me too.

Flags: needinfo?(bugs)

(In reply to Alice0775 White from comment #35)

I can reproduce the issue with str comment#0 and comment#23 in trybuild(20211022182331).
And cannot reproduce with non-fission.

Olli, looks like Alice can still reproduce the bug with your try build (last month).

Fission Milestone: MVP → ---
Flags: needinfo?(bugs)
Whiteboard: fission-soft-blocker → [fission]

Yes. The issue is that I haven't managed to reproduce the issue ever and I think peterv has seen it once.
So fixing this is really hard.
I wonder why this is so hard to reproduce for us.

Flags: needinfo?(bugs)

comment #0 and comment #23 easily reproduces on my machine (I didn't have to be "furious"), so I maaay be able to help here...

Requested index handling is very fragile. We should try to figure out a way to remove it altogether.
(But unfortunately some behavior similar to it is needed in certain cases).
The patch is a stop-gap solution.

Attachment #9261580 - Attachment description: WIP: Bug 1729545, Try to ensure session history loads can't get stuck because of bogus requested index, r=peterv → Bug 1729545, Try to ensure session history loads can't get stuck because of bogus requested index, r=peterv
Pushed by opettay@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/3ba966335c7b
Try to ensure session history loads can't get stuck because of bogus requested index, r=peterv
Status: REOPENED → RESOLVED
Closed: 10 months ago7 months ago
Resolution: --- → FIXED
Target Milestone: --- → 98 Branch
Flags: qe-verify+
Duplicate of this bug: 1728842

I could not reproduce the issue on Win10x64 using build 95.0a1 (20211019095357) and steps from comments 23 and 0.
Is the issue still reproducing on your side? using latest 98.0b4(https://bugzilla.mozilla.org/show_bug.cgi?id=1729545#:~:text=side%3F%20using%20latest-,98.0b4,-%3F)?

Flags: needinfo?(alice0775)

(In reply to Monica Chiorean from comment #44)

I could not reproduce the issue on Win10x64 using build 95.0a1 (20211019095357) and steps from comments 23 and 0.
Is the issue still reproducing on your side? using latest 98.0b4(https://bugzilla.mozilla.org/show_bug.cgi?id=1729545#:~:text=side%3F%20using%20latest-,98.0b4,-%3F)?

I also can't reproduce the problem with Firefox 98.0b4 (build ID 20220213185901).

Status: RESOLVED → VERIFIED
Flags: needinfo?(alice0775)

I noticed this was closed and was linked to my dupe. But this is happening for me still. Just came back from being out, woke up my PC, opened a new window, searched and clicked a link, closed window, ctrl+shift+n to re-open it, hit back but it just "refreshes" the page does not go back. Forward and back go to the same page.

Nightly 99, linux, for reference

That's a different issue since this was about the navigation not responding at all. Could you open a new issue with:

  1. The name of the search engine
  2. The link you clicked (even if it was a random click)

Thanks!

It "responds", but the page is incorrect.

Should I re-open https://bugzilla.mozilla.org/show_bug.cgi?id=1728842 ?

Comment 46 seems to talk about some session restore issue. zlice, could you file a new bug about that and have steps to reproduce there, thanks.

Flags: needinfo?(zlice555)

That isn't session restore. That's a running session I came back to after leaving it up for a while.

Flags: needinfo?(zlice555)

Thanks, but please file a new issue and then we can figure out whether it's indeed a new issue or a duplicate of something else.

You need to log in before you can comment on or make changes to this bug.