Open Bug 1518788 Opened 9 months ago Updated 5 months ago

The Back button is active in a newly opened tab if the tab is opened by default

Categories

(Core :: Document Navigation, defect, P3)

defect

Tracking

()

Tracking Status
firefox64 --- wontfix
firefox65 --- fix-optional
firefox66 --- fix-optional
firefox67 --- fix-optional
firefox68 --- fix-optional

People

(Reporter: oana.botisan, Unassigned)

Details

(Keywords: regression)

Attachments

(1 file)

Attached video back button active.mov

[Affected versions]:

  • Latest Nightly 66.0a1
  • beta 65.0b9
  • Firefox 64.0.2

[Affected platforms]:

  • Windows 10 x64
  • Ubuntu 16.04 x64
  • macOS 10.14

[Prerequisites]:

  • Visit a site that opens the links in a new tab by default, like the one in the steps.

[Steps to reproduce]:

  1. Go to https://www.aliexpress.com/wholesale?catId=0&initiative_id=SB_20190109053920&SearchText=water+bottle.
  2. Click on one of the items.
  3. Look at the Back button on the new opened tab.

[Expected result]:

  • The button is not active.

[Actual result]:

  • The button is active, but it doesn't do anything if it's clicked.

[Regression range]:

  • I don't know if it's a regression, but I will try to find as soon as possible.

[Additional notes]:

  • Please look at the attached gif.
  • This doesn't happen if a link is open manually in a new tab by using the middle click or Ctrl+click etc.

When asked, SessionHistory returns an object with 2 entries, which are completely identical. I assume this comes from docshell, so moving there.

Component: Toolbars and Customization → Document Navigation
Product: Firefox → Core

I think this is a regression. I am not abled to reproduce the issue on builds older than 2-10-07-11.

Keywords: regression

ni?'ing self to look at when I have time.

Flags: needinfo?(kyle)

I can't seem to repro this? Tried on 2019-01-17 Nightly with a fresh profile on Windows and Linux, went through STR, but I don't get the back button being activated after the new tab comes up.

We're doing a ton of work around this code right now, so it could be that this was fixed sometime in the past week.

Flags: needinfo?(kyle)

I can still reproduce the issue on the latest Nightly, but it's intermittent now. I can reproduce it half the time and mostly when I use the middle-click to open the page (it's a habit, I know in this situation is not necessary).

Has Regression Range: --- → yes

I'm able to repro using STR on mac OS and nightly 66.0a1. As Gijs indicated, Bug 1509231 could be related.

Adding ni for qdot again to look into it.

Flags: needinfo?(kyle)
Priority: -- → P3

Ok, this didn't work for me the first time around because I was using a profile with Content Blocking enabled. If Content Blocking is on, I can't repro this, but turning it off triggers the bug fairly regularly. It looks like there's some sort of subdocument load that happens near the end of the load chain that may be causing this (and is blocked by content blocking), which is inserting an extra duplicate entry into history along the way. Not really sure what we're supposed to be doing in that situation.

  • Chrome doesn't present a back button in the new tab
  • Safari presents a back button, but that closes the new tab and returns to the original.

I'll assign this to myself to follow up on.

Assignee: nobody → kyle
Flags: needinfo?(kyle)
Assignee: kyle → nobody
You need to log in before you can comment on or make changes to this bug.