Open Bug 1528958 Opened 6 years ago Updated 2 years ago

[Bing search page] - Functionality error of the back button attempting to return to the previous page after a searching term process

Categories

(Web Compatibility :: Desktop, defect, P1)

Product:
Web Compatibility
Component:
Desktop
Type:
defect

Tracking

(Webcompat Priority:P2, firefox-esr91 affected, firefox67 wontfix, firefox68 wontfix, firefox69 wontfix, firefox70 wontfix, firefox71 wontfix, firefox72 wontfix, firefox73 wontfix, firefox87 affected, firefox103 affected, firefox111 affected)

Status:
ASSIGNED
Project Flags:
Webcompat Priority P2
Tracking Flags:
Tracking Status
firefox-esr91 --- affected
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- wontfix
firefox70 --- wontfix
firefox71 --- wontfix
firefox72 --- wontfix
firefox73 --- wontfix
firefox87 --- affected
firefox103 --- affected
firefox111 --- affected

People

(Reporter: liviu.seplecan, Assigned: twisniewski)

References

(
URL
)

Details

(Keywords: webcompat:needs-diagnosis)

Attachments

(1 file)

iframe-form-history.html
(deleted), text/html
Details

[Platform affected]: Windows 10, Ubuntu 16.04, Mac OS X

[Firefox versions]: latest nightly 67.0a1, beta 66.0b9, release 65.0.1

Steps to reproduce:

  1. Access the link: https://www.bing.com/
  2. In the input search type any word
  3. After the results are displayed, click on the back button (top left side).

Expected result: the user should be redirected back to the main (default page) or at the previous page.

Actual results: Nothing happens by pressing on back button. It will be necessary to click or double-click for many times to the back button to get a response. Please see the video link attached: https://streamable.com/88s2t

Note: If you attempt to do the above actions on Yahoo-search, clicking on back button will work without any problems.

This appears to be something to do with Bing themselves and not Firefox. They've changed something which has caused an intermediate redirect, and when you attempt to go back it redirects you to the first page again.

I don't think we can do much here, though we might have some contacts who could help. NI to Mike.

Flags: needinfo?(mozilla)

Hi Mark, got it. So, please let me know when it will be decided what Status should have this bug. Thanks

This works in Chrome, though, so it's a webcompat issue. I wonder if it is:

https://bugzilla.mozilla.org/show_bug.cgi?id=148794

Flags: needinfo?(mozilla)

Ok, moving across to Web compatibility for now at least.

Component: Search → Desktop
Product: Firefox → Web Compatibility

Ok, Thanks

Interesting, this doesn't reproduce with uBlock enabled.

Tom, can you take a look please?

Flags: needinfo?(twisniewski)
Priority: -- → P1

I can also see an extra history entry after doing a simple search. When I hit back after the search, it's just skipping forward again, and I see a request being made to https://login.microsoftonline.com/common/oauth2/authorize in the devtools. The response of that request is this 200/OK document (with some bits snipped for brevity):

<html><head><title>Working...</title></head><body>
<form method="POST" name="hiddenform" action="https://www.bing.com/orgid/idtoken/nosignin">
<input type="hidden" name="error" value="login_required" />
<input type="hidden" name="error_description" value="AADSTS50058: A silent sign-in request was sent but no user is signed in." /></form>
<script language="javascript">document.forms[0].submit();</script>
</body></html>

So that explains why "back" isn't working properly; it just directs us forward again.

According to the devtools timeline, that specific request is being made during page-load in a subdocument, and indeed as the page loads it adds this iframe:

<iframe id="aadssofr" src="https://login.microsoftonline.com/common/oauth2/authorize?snip for brevity" sandbox="allow-forms allow-pointer-lock allow-popups allow-same-origin allow-scripts" style="visibility: hidden; position: absolute; height: 0px; width: 0px; border: medium none;" data-bm="45"></iframe>

So the addition of the iframe must be adding a history entry as well. A search for aadssofr in their sources reveals it happens in this SSO script in both browsers:

var SsoFrame;
(function(n) {
    function t(n) {
        if (n && n.url && n.sandbox) {
            var t = sj_ce("iframe")
              , i = t.style;
            i.visibility = "hidden";
            i.position = "absolute";
            i.height = "0";
            i.width = "0";
            i.border = "none";
            t.src = decodeURIComponent(n.url);
            t.id = "aadssofr";
            t.setAttribute("sandbox", n.sandbox);
            _d.body.appendChild(t);
            n.currentEpoch && sj_cook.set("SRCHUSR", "T", n.currentEpoch, !0, "/")
        }
    }
    function i(n) {
        try {
            n && n.length === 2 && t(n[1])
        } catch (i) {}
    }
    n.createFrame = t;
    n.ssoFrameEntry = i;
    sj_evt.bind("ssoFrameExists", i, !0, null, !1)
}
)(SsoFrame || (SsoFrame = {}))

It seems that Chrome is not adding a history entry for this iframe when that code is run, but Firefox is.

@miketaylr, didn't the Chromium team work on hiding these kinds of "extra" history entries from the UI at some point?

Flags: needinfo?(twisniewski) → needinfo?(miket)

Does this still happen on the latest nightly? Supposedly we put some fixes in related to this:

https://bugzilla.mozilla.org/show_bug.cgi?id=1489308

I was just testing on the current Linux nightly, so the answer must be yes. Maybe adding an iframe doesn't trigger the same potential history-altering behavior as window.open?

Liviu, could you please re-test this in Nightly?

Flags: needinfo?(miket) → needinfo?(liviu.seplecan)

Hi @Mike, I've tested on the latest Nightly 68.0a1, even beta 67.0b19 and release 66.0.5.
The functionality error of back button occurs only at the 1st term inserted - but to move to the next search term, in a normal behavior, other actions should be involved (many clicks on the back button, refreshing of the page). So, in conclusion, on my end the issue still happens.

Flags: needinfo?(liviu.seplecan)

Reproducible on latest Nightly 69.0a1 (2019-07-04).

status-firefox69: --- → affected

This issue is also reproducible on latest Nightly 73.0a1 (2019-12-04).

status-firefox73: ? → affected

I've been suffering with this for a while now :(.

The back button doesn't work well at all and I have to RIGHT CLICK the back button to get a history of the previous pages/searches in order to go back in Bing.

I can sometimes go back after clicking a few times on the back button but then I can't go forward anymore, it deletes the pages/search history, strange enough.

This is about the only issue I have with Firefox. I tried with Vivaldi and it works well (but the browser itself has so many bugs that it's unusable).

Bing is a major search engine and a popular page to visit, it's a bit of a surprise that this issue has been active since February 2019 (and who knows from when before that). I thought it was new from this year. Hope it can be fixed soon or I'll have to move to another search engine.

Forgot to mention that I've had this issue in Firefox v71-76. Not sure about previous versions as I switched to Bing late last year.

Attached file iframe-form-history.html (deleted) —

It seems like this is another instance of Bug 208835... I wonder what the possible fallout could be from fixing a 17 year old bug, or if it would just make the web less annoying in Firefox.

Depends on: 208835

I tested with private windows a few times and (I do have most extensions active in private window/incognito) and Bing seems to work much better.
I also tested with non-private window (normal mode) by disabling all my extensions (meaning to use safe mode) and the Bing issue remains. Hope this can be resolved for the next Firefox version!

Any thoughts Nika? (See Comment #18)

Flags: needinfo?(nika)

This seems very similar to the issue from bug 1397512, where a form was being submitted from within an onload handler. In this case, the code is dodging the check due to the code being run during document parsing, rather than during onload.

I imagine we'll probably want to change the code added in bug 1397512 to check if the load is happening before the load event has been fired, rather than specifically checking that it's during the load event.

ni? :smaug who wrote that patch originally, and might know more.

Flags: needinfo?(nika) → needinfo?(bugs)
Webcompat Priority: --- → P2
Severity: normal → S3

The issue still occurs on my side.

Tested with:
Browser / Version: Firefox Nightly 87.0a1 (2021-01-28)
Operating System: Windows 10 Pro

status-firefox87: --- → affected
Keywords: webcompat:needs-diagnosis

Same here. Still happening and it's very annoying. We don't all use Google search or DuckDuckGo, you know.
Either way, I'll be moving to Edge soon as Firefox keeps slowing down my high-end computer (Alienware m17 R3 - 2020) every 2-3 days if I don't restart it. Edge is adding lots of good features lately. Quick development also. Firefox is still my favourite browser but I've been suffering with that slow down for years now across multiple different laptops so it doesn't seem to be something that Mozilla can fix. And, this Bing bug ruins the experience when searching. No other browser has an issue with this (unsure about Firefox forks) :/..

Assignee: nobody → twisniewski

The issue still occurs on my side.

Tested with:
Browser / Version: Firefox Nightly 103.0a1 (2022-06-09)
Operating System: Windows 10 Pro

status-firefox103: --- → affected

This issue is also reproducible on Firefox 91.11.0 esr. Tested on Ubuntu 22.04.

status-firefox-esr91: --- → affected
Status: NEW → ASSIGNED
status-firefox111: --- → affected

We recently talked about Bing with peterv and it seems to rely on the user interaction intervention.

Flags: needinfo?(smaug)

This is still NOT resolved after 4 years. Version 110.0.1
Search for something in Bing, then search for something else, press the back button in the browser or mouse and you stay on the same page. It doesn't go back to previous page.

Does Mozilla Firefox have any intention in fixing this?
Why are they against Bing?

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

Attachment

General

Creator:
Created:
Updated:
Size: