Closed Bug 1750152 Opened 3 years ago Closed 3 years ago

Bing settings no longer persistent when changed, only in Firefox

Categories

(Web Compatibility :: Site Reports, defect, P1)

Product:
Web Compatibility
Component:
Site Reports
Version:
Firefox 96
Type:
defect

Tracking

(firefox-esr91 unaffected, firefox96+ fixed, firefox97+ fixed, firefox98+ fixed)

Status:
RESOLVED FIXED
Tracking Flags:
Tracking Status
firefox-esr91 --- unaffected
firefox96 + fixed
firefox97 + fixed
firefox98 + fixed

People

(Reporter: excloudymat, Assigned: denschub)

References

(Regression)

Details

(Keywords: perf-alert, regression, webcompat:site-wait, Whiteboard: [necko-triaged])

Attachments

(2 obsolete files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

  1. Go to Bing.com
  2. Open Settings
  3. Make changes to any settings except the ones relating to "Home Page" at the bottom. For instance, set a zip code or change language
  4. Save settings

Actual results:

Go back to Open Settings in Bing - your changes have been lost. It does this whether you're logged in or not, regardless of operating system, and only in Firefox 96

Expected results:

Settings should persist within that session.

Quick check on Reddit throws up a few other users experiencing the same issue, see https://www.reddit.com/r/firefox/comments/s1rilz/sudden_issues_with_bing_preferences/

The Bugbug bot thinks this bug should belong to the 'Firefox::Preferences' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Component: Untriaged → Preferences

Bot misclassified component due to reference to 'preferences'. This is not an issue with Firefox preferences, more likely something to do with privacy, security and/or cookie handling.

Component: Preferences → Untriaged

I'm wondering if this might be related to bug 1748693, which we rolled out a remote pref flip for today to hopefully mitigate. Reporter, can you check about:support to see if you have bug-1750257-rollout-pref-off-networkcookiesamesiteschemeful-in-release-96-96 listed in the "Remote Features" section and if yes, does the Bing issue still reproduce for you? Thanks!

Flags: needinfo?(excloudymat)

Thanks. Cross site scripting protection treating HTTP cookies as not equivalent for an HTTPS site did look rather promising, but the fix did not have any effect, at least in my testing. Just to be clear, from bug 1748693 I understood the solution there was to flip network.cookie.sameSite.schemeful to false as the fix, and it had no impact on this situation, preferences are still not persisted outside the preferences page itself.

In further testing, I did find an interesting artifact which might shed further light. There's only one setting which can be configured outside the settings page, which is the level of SafeSearch. All other times, when you press 'save' it takes you to another page, losing the change. However, one can search for images and change the SafeSearch level within the results page. In this case, the effect does persist. However, when you click on any result it takes you to a new tab (another setting you can change when settings work) and when you go to the tab the SafeSearch level has reset again. I don't know enough about browsers to make any firm conclusions about cookies & session cookies, but it feels significant for whatever is causing this.

Flags: needinfo?(excloudymat)

If you're up for doing more testing, tracking down a regression range with the mozregression tool would be super helpful too.
https://mozilla.github.io/mozregression/

Let me have a go at that.

Well that was fun. I went all the way back to 2021-01-01 (nightly build of v86) and the effect is still there. Looks like we should close and I'll find a way to let Bing know? Any pointers here would be very helpful, I couldn't easily find a way to file a bug for Bing.

Tweeted, filed a report via Webmaster tools and Feedback. Is there's any interface from Firefox to major sites when there are compatibility issues? This is making Firefox unusable for any desktop user outside the USA, and anyone who wants to stay logged into Bing or change any preferences.

In about:config, does setting network.cookie.sameSite.laxByDefault to false change anything?

Wow, yes, that fixes it! What's the thinking there?

It's a feature which was enabled on Nightly builds for a long time but only shipped to users on release in 96.

Blocks: sameSiteLax-breakage
Status: UNCONFIRMED → NEW
status-firefox96: --- → affected
status-firefox97: --- → affected
status-firefox98: --- → affected
status-firefox-esr91: --- → unaffected
Component: Untriaged → Networking: Cookies
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
Regressed by: samesitelax
Has Regression Range: --- → yes
Flags: needinfo?(ngogge)

This bug does not affect any of my other browsers, Chrome, Edge or IE

FWIW this is not currently affecting Firefox on iOS even though it’s also v96. Just Windows & macOS (haven’t been able to test Linux).

(In reply to Mat Ellis from comment #15)

FWIW this is not currently affecting Firefox on iOS even though it’s also v96. Just Windows & macOS (haven’t been able to test Linux).

Firefox for iOS doesn't use the same underlying engine as on other platforms, so this is expected.

:dveditz do you have any insight on the impact of this?

Flags: needinfo?(dveditz)

TL;DR: Bing gives different (correct) cookies to Chrome. If I spoof a Chrome userAgent they send explicit SameSite=None cookies and the site works fine.

When you save the Bing settings it POSTs the changes to an /account? URL that redirects back to the main Bing page. The redirect has a Set-Cookie: header that contains the settings you just POSTed to the site.

  • In Firefox the cookie has no SameSite attribute, and as-of Fx96 it becomes "SameSite=lax"
  • for Chrome browsers the site sends the same cookie with ; secure; SameSite=None at the end

On Firefox, but not on Chrome that I can see, the Bing page includes two invisible iframes to automatically log in users. One is to a login.microsoftonline.com OAuth2 URL, and the other is login.live.com.

The login.microsoftonline.com frame navigates to the specified https://www.bing.com URL, but the SameSite=lax cookies are NOT sent. Without the cookies the reply resets the "missing" cookies to the default values.

The login.live.com frame is similar, except it 302 redirects to a (different) Bing URL. It also does not send the lax-by-default cookies, and the site responds by resetting the missing cookies again.

Normally "lax" SameSite cookies are sent for navigations (including redirects), but that only applies to TOP-LEVEL loads, not frames as in this case. The spec says

  • If the cookie's same-site-flag is not "None" and the retrieval's same-site status is "cross-site", then exclude the cookie unless all of the following conditions are met:
    • The retrieval's type is "HTTP".
    • The same-site-flag is "Lax" or "Default".
    • The HTTP request associated with the retrieval uses "safe" method.
    • The target browsing context of the HTTP request associated with the retrieval is a top-level browsing context.

We're following the spec, and it's enforcement of the last 6 words there that are the final step in this breakage. Given that Bing gives Chrome browsers explicit SameSite=None cookies I assume there's no argument from the Bing folks about the spec on this point.

Flags: needinfo?(ngogge)
Flags: needinfo?(dveditz)

This has come up a few times on SUMO for users that modify the SafeSearch setting.

While evangelism seems best, it does work as a temporary workaround to add www.bing.com to network.cookie.sameSite.laxByDefault.disabledHosts. I noticed it does not work to add just bing.com to the list.

Severity: -- → S3
Priority: -- → P1
Whiteboard: [necko-triaged]

I've reached out to Microsoft people, and I'll update this bug if I hear something back.

Keywords: webcompat:site-wait
Assignee: nobody → dschubert
Status: NEW → ASSIGNED

Comment on attachment 9259781 [details]
Bug 1750152 - Beta - Add a UA Override to Bing.com. r?twisniewski!

Beta/Release Uplift Approval Request

  • User impact if declined: Users of bing.com will not be able to save adjusted settings (like the Safe Search level, for example)
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: Yes
  • If yes, steps to reproduce: STR from comment 0 should no longer reproduce. In addition, this needs smoketesting by QA to make sure we don't break Bing.
  • List of other uplifts needed: None
  • Risk to taking this patch: Medium
  • Why is the change risky/not risky? (and alternatives if risky): I can't really estimate the risk here -- shipping a UA override to a site this complex can have all sorts of unknown unknowns.

As discussed with :RyanVM on Slack, we should be doing some testing internally first, and then use Beta as a way to get some additional testing done to make sure we don't break Bing in a critical way.

  • String changes made/needed:
Attachment #9259781 - Flags: approval-mozilla-beta?
Flags: qe-verify+

""""In about:config, does setting network.cookie.sameSite.laxByDefault to false change anything?""""
This has fixed the unable to set options in Bing.
Also has fixed a problem in Facebook where it would not display old messages and quite a lot of pictures that were blanked out with a text saying something on the lines of ""May be a picture of a beach" it's still saying that but if clicked on it is displaying the picture correctly.

Comment on attachment 9259781 [details]
Bug 1750152 - Beta - Add a UA Override to Bing.com. r?twisniewski!

Approved for 97.0b6 so we can get some real-world testing of this override before deciding what to do about 96 next week.

Attachment #9259781 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

(In reply to jscher2000 from comment #20)

it does work as a temporary workaround to add www.bing.com to network.cookie.sameSite.laxByDefault.disabledHosts. I noticed it does not work to add just bing.com to the list.

If you check the cookies in DevTools you'll see they are "domain" cookies with a value ".bing.com". Adding "bing.com" to the list without the leading dot effectively only disables laxByDefault for "host" cookies on the site http(s)://bing.com (if there was a site there) but not any subdomains. Adding "www.bing.com" disables laxByDefault for www.bing.com host cookies and .bing.com domain cookies.

I have reproduced the issue using Firefox 96.0.1 and verified the fix using Firefox Beta 97.0b6 on Windows 10, MacOS 11.6 and Ubuntu 20.04.

I've also played around with the settings, performed several searches/scenarios to see if anything got broken by the fix but I did not run into any issues on my end.

status-firefox97: fixed → verified
Attachment #9259746 - Attachment is obsolete: true
QA Whiteboard: [qa-triaged]

Microsoft has informed us that they've rolled out a fix for this issue on their end.

Comment on attachment 9259781 [details]
Bug 1750152 - Beta - Add a UA Override to Bing.com. r?twisniewski!

This isn't needed anymore.

Attachment #9259781 - Flags: approval-mozilla-beta+ → approval-mozilla-beta-

UA override backed out from 97.0b8.
https://hg.mozilla.org/releases/mozilla-beta/rev/9d1e2d5b2945

Closing this bug out as fixed by Microsoft. Feel free to NI me if you're still seeing issues and we can follow-up with them.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
status-firefox96: affected → fixed
status-firefox97: verified → fixed
status-firefox98: affected → fixed
Component: Networking: Cookies → Desktop
Flags: qe-verify+
Product: Core → Web Compatibility
Resolution: --- → FIXED

(In reply to Ryan VanderMeulen [:RyanVM] from comment #27)

https://hg.mozilla.org/releases/mozilla-beta/rev/249ef1b30c35

== Change summary for alert #33062 (as of Tue, 25 Jan 2022 15:22:48 GMT) ==

Improvements:

Ratio Test Platform Options Absolute values (old vs new)
5% expedia ContentfulSpeedIndex windows10-64-shippable-qr warm webrender 412.35 -> 391.75
5% expedia fnbpaint windows10-64-shippable-qr warm webrender 310.62 -> 296.62

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=33062

(In reply to Ryan VanderMeulen [:RyanVM] from comment #32)

UA override backed out from 97.0b8.
https://hg.mozilla.org/releases/mozilla-beta/rev/9d1e2d5b2945

Closing this bug out as fixed by Microsoft. Feel free to NI me if you're still seeing issues and we can follow-up with them.

== Change summary for alert #33096 (as of Wed, 26 Jan 2022 14:51:08 GMT) ==

Regressions:

Ratio Test Platform Options Absolute values (old vs new)
30% espn fcp android-hw-g5-7-0-arm7-shippable-qr warm webrender 1,095.12 -> 1,419.04
29% espn fnbpaint android-hw-g5-7-0-arm7-shippable-qr warm webrender 1,115.67 -> 1,440.12
6% expedia fcp windows10-64-shippable-qr warm webrender 276.56 -> 292.62
5% expedia fnbpaint windows10-64-shippable-qr warm webrender 292.39 -> 306.10

Improvements:

Ratio Test Platform Options Absolute values (old vs new)
6% amazon fnbpaint linux1804-64-shippable-qr warm webrender 278.75 -> 261.17
6% amazon dcf linux1804-64-shippable-qr warm webrender 286.48 -> 268.67
6% amazon fnbpaint macosx1015-64-shippable-qr fission warm webrender 211.96 -> 199.33
6% amazon dcf macosx1015-64-shippable-qr fission warm webrender 217.88 -> 205.04
6% buzzfeed fcp macosx1015-64-shippable-qr warm webrender 340.96 -> 321.62
... ... ... ... ...
2% youtube-watch dcf android-hw-g5-7-0-arm7-shippable-qr warm webrender 1,443.70 -> 1,414.79

For up to date results, see: https://treeherder.mozilla.org/perfherder/alerts?id=33096

Attachment #9259781 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: