1447524 - Double session history entries from https://www.microsoft.com/en-us/news

Status: NEW

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

Description

[Ken Riley]

User Agent: Mozilla/5.0 (Android 5.1; Tablet; rv:60.0) Gecko/60.0 Firefox/60.0
Build ID: 20180319175655

Steps to reproduce:

From home screen or any other tab with Request desktop site checked, navigate to https://www.microsoft.com/en-us/news
Press back button (Firefox or Android)


Actual results:

Microsoft site is still active


Expected results:

Returned to previous site within tab

Stable Firefox 59.0.1 gives expected results.

I'm using Verizon Ellipsis 10 tablet with Android 5.1.

Comment 1

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Thanks for reporting - to be clear, you were able to reproduce on Nightly but not on the release channel?

[triage] Critical: back doesn't work and we don't know which websites it might affect. Especially problematic as a regression.

Comment 2

[:sdaswani]

Ritu would this need to land by end of this week?

NI'ing Petru to assign it out to Vlad, Andrei or Petru, not sure why I can't assign one myself.

Comment 3

[Jan Henning [:JanH]]

For some reason loading that URL seems to create two session history entries on Android.

Comment 4

[Ken Riley]

To be clear, the bug I reported was with Beta 60.

Comment 5

[Petru-Mugurel Lingurar [:petru]]

I have investigated this and found that on Android the back button action is handled properly.
Android delegates  browser.js  using  EventDispatcher.getInstance().dispatch("Session:Back", null) to handle the event and the problem seems to be there. Indeed nothing happens the first time. Same call, the second time, will indeed take the user to the previous page.

Comment 6

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

If this is a new regression in 60, you have until the week of April 23rd (pre-RC week) to uplift fixes that are safe and high likelihood to fix the regression. If this falls under "new feature" planned work, the sooner we uplift the better. If it doesn't happen this week but instead next, we can decide based on risk vs reward. Julien (as 60 release owner), please add anything I may have missed.

Comment 7

[:sdaswani]

Thanks Ritu! This is a regression since 59.0.1 is ok.

I’m sure Petru will have a fix soon.

Comment 8

[Petru-Mugurel Lingurar [:petru]]

Investigated more.
The problem is definitely in core.
It's not only the back button that doesn't take the user back from https://www.microsoft.com/en-us/news
It's any other action that would have that effect, like pressing the back arrow from the options menu.
Because they all delegate the core to actually do the intended action.

What's more, this issue is also happening on Desktop (Ubuntu) latest stable - 59.0.2

Comment 9

[:sdaswani]

James, it looks like this is a platform issue - can someone on your team take a look?

Comment 10

[Jan Henning [:JanH]]

Attachment: shistory.json

Loading that page generates two session history entries like in the attached session store extract.

In the static HTML markup, the corresponding iframe is defined as
> <iframe id="shell-cart-count" title="Items in the cart" data-src="//www.microsoft.com/store/buy/cartcount" style="display: none"></iframe>
and later on, a script copies the contents of the data-src attribute into the proper "src" attribute to actually load that page.

For some reason, the page loads in such a way that it generates these two history entries, one before the iframe has loaded and one afterwards. On Desktop, I can also see the reload button momentarily flash between cancel and reload once more.

Comment 11

[Marion Daly [:mdaly]]

:overholt on your radar

Comment 12

[Marion Daly [:mdaly]]

Regression range: ::::

Comment 13

[Sorina Florean [:sflorean]]

Tested with Nexus 7(Android 5.1.1) and the issue is reproducible also with build from 2017-07-01 so this doesn't seems to be a regression. I tried with some other sites like cnn.com, youtube, amazon, some search with google and the issue is not reproducible.

Comment 14

[Andrew Overholt [:overholt]]

(In reply to :sdaswani from comment #7)
> Thanks Ritu! This is a regression since 59.0.1 is ok.
[...]
(In reply to Sorina Florean [:sorina] from comment #13)
> Tested with Nexus 7(Android 5.1.1) and the issue is reproducible also with
> build from 2017-07-01 so this doesn't seems to be a regression.

Ah. I'll remove the regression keyword.

> I tried with
> some other sites like cnn.com, youtube, amazon, some search with google and
> the issue is not reproducible.

Nika and I discussed this; she opined it could be a website bug? Sorina, can you compare other browsers on desktop?

Peter, can you take a look (this reproduces on desktop) at comment 10?

Comment 15

[Sorina Florean [:sflorean]]

Tested on WIN 10x64 with the following browsers:
-Chrome - not reproducible
-Microsoft Edge - not reproducible
-Opera - not reproducible
-Vivaldi - not reproducible
-Firefox and Nightly - reproducible
-Tor browser - reproducible (https://www.torproject.org/projects/torbrowser.html.en)

Seems that is only reproducible with Firefox and Tor browsers from my list. Also, from mobile side on Chrome, DuckDuckGo and Opera the issue is not reproducible. But with Firefox and Orfox: a Tor Browser for Android the issue is reproducible. 

If there is some other particular browsers that needs to be tested, please let me know.

Comment 16

[Andrew Overholt [:overholt]]

Thanks, Sorina, that's great!

At this point I think it's worth filing this as a web compat issue which I've done: https://webcompat.com/issues/16638. Let's wait for some analysis from them and then we'll see what needs to happen.

Comment 17

[Karl Dubost💡 :karlcow]

This is happening in 58.

Comment 18

[Chris Peterson [:cpeterson]]

Removing the regressionwindow-wanted keyword because I can reproduce this bug at least as far back as Firefox 43. I see now that Sorina already noted that this was not a regression (in comment 13). :)

Comment 20

[Karl Dubost💡 :karlcow]

There is a detailed analysis by Thomas on the origin of the issue.
https://webcompat.com/issues/16638#issuecomment-421518538

Comment 21

[Karl Dubost💡 :karlcow]

Thomas this seems to be another case for it.

Comment 22

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 23

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 24

[Thomas Wisniewski [:twisniewski]]

Attachment: test.html

Yes, this does seem to be the same. In fact, I've finally found some time to make a mostly-reduced test-case. The requirements to reproduce the issue seem to be:

1. Use requireJS to define and require a module
2. Have that module change an iframe's src
3. Have that iframe post a message to the parent

But after reducing that far, I really need a break.

Nika, do you figure this is basically being caused by what you mentioned here on webcompat.com?

Comment 26

[Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi]]

Adam is working on https://bugzilla.mozilla.org/show_bug.cgi?id=340021. Let's see if he has quick thoughts on what's up here. Or can this be resolved by his patches?

Comment 27

[Adam Vandolder [:avandolder]]

This issue should be fixed when the back-button intervention is re-enabled.

Comment 28

[Calin Tanase]

The issue is still reproducible on both Release and Nightly but not on Chrome.

Environment:
Operating system: Windows 10
Browsers tested: Firefox Nightly 128.0a1 (2024-05-28) / Firefox Release 126 / Chrome 125.0.6422.113