[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.

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

• good: 2017-07-11
• bad: 2017-07-12
• pushlog:https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0e41d07a703f19224f60b01577b2cbb5708046c9&tochange=09a4282d1172ac255038e7ccacfd772140b219e2

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

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.

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).

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.

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.

This issue is reproducing on Firefox 76.0b1. STR:

1. Reach to "about:protections".
2. Click on the Protection Level button.
3. Observe the "Go back a Page" button.

Expected Results:

• The button is not active.

Actual Results:

• The button is active.

The Aliexpress case was probably solved by bug 1515073, interested in the about:protections/about:preferences thing...