Closed Bug 1620104 Opened 4 years ago Closed 3 years ago

FF75.0a1: Visualforce pages embedded in Salesforce standard page failing in Nightly

Categories

(Core :: Networking: Cookies, defect, P2)

Desktop
macOS
defect

Tracking

()

RESOLVED FIXED
Tracking Status
firefox-esr68 --- unaffected
firefox-esr78 --- disabled
firefox73 --- unaffected
firefox74 --- unaffected
firefox75 --- disabled
firefox76 --- disabled
firefox77 --- disabled
firefox78 --- disabled
firefox79 + wontfix
firefox80 + wontfix

People

(Reporter: kwilson, Unassigned)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [necko-triaged])

Attachments

(3 files)

Starting on March 3, after I updated Firefox Nightly on my system, the Common CA Database (CCADB) stopped displaying pages correctly. I updated Nightly today, turned DoH on/off, tried changing cookie settings, and created a new user profile. Nothing seems to help. The problem is not happening in Beta or Release.

Attached is a screenshot showing the problem. The left side shows how it is supposed to look, and how it does look in Beta and Release. The right side shows the problem in Nightly. notice the "Case Progress" and "Messages" sections of the page.

Here is a description of those sections from the CCADB Salesforce admin:
The Progress Bar and Message sections are Visualforce pages embedded in Salesforce standard page. The Visualforce framework includes a tag-based markup language similar to HTML, and a set of server-side “standard controllers” that make basic database operations. Visualforce programs contain Visualforce tags, HTML, JavaScript, or any other Web-enabled code embedded within a single <apex:page> tag. I have attached the program files so that you can view the code behind the two embedded components.

Attaching the program files so that you can see the code behind the two embedded components.

Attached file CaseProgressBar.txt

Kathleen, would you mind running mozregression to find out when/what exactly broke this? The quick start guide at https://mozilla.github.io/mozregression/ should be helpful with this.

Flags: needinfo?(kwilson)

Oh, and is this perhaps fixed if you toggle network.cookie.sameSite.laxByDefault to false in about:config ?

(In reply to :Gijs (back Thu 12; he/him) from comment #4)

Oh, and is this perhaps fixed if you toggle network.cookie.sameSite.laxByDefault to false in about:config ?

Yes, that fixes the problem. Thanks!

Should I close this bug as WORKSFORME?

Flags: needinfo?(kwilson)

(In reply to Kathleen Wilson from comment #5)

(In reply to :Gijs (back Thu 12; he/him) from comment #4)

Oh, and is this perhaps fixed if you toggle network.cookie.sameSite.laxByDefault to false in about:config ?

Yes, that fixes the problem. Thanks!

Should I close this bug as WORKSFORME?

Great. No, we should keep the bug open and figure out why salesforce is upset when we treat their cookies as samesite=lax. :-)

Kathleen, do you know if the Visualforce pages are served from a different domain than the parent salesforce page? If you're not sure, you may be able to find out using "View Frame Info" in the context menu, when the page is working correctly, or by using the devtools inspector to inspect the frames to see what their src attribute is.

Component: General → Networking: Cookies
Flags: needinfo?(kwilson)
OS: iOS 10 → macOS
Product: Firefox → Core
Regressed by: 1604212
Has Regression Range: --- → yes

(In reply to :Gijs (back Thu 12; he/him) from comment #6)

Kathleen, do you know if the Visualforce pages are served from a different domain than the parent salesforce page? If you're not sure, you may be able to find out using "View Frame Info" in the context menu, when the page is working correctly

View Frame Info
Title: Salesforce - Enterprise Edition
Address: https://ccadb--c.na74.visual.force.com/servlet/servlet.Integration?lid=0661J000003Jmx0&ic=1&linkToken=VmpFPSxNakF5TUMwd015MHhNMVF5TWpveU1qbzBNUzR6TWpkYSxib0hJOXRac0VucmJYOEd6Z1VvdEM0LFlXWmtNR0po
Type: text/html
Render Mode: Standards compliance mode
Text Encoding: UTF-8
Referring URL: https://ccadb.my.salesforce.com/

Flags: needinfo?(kwilson)

(In reply to Andrea Marchesini [:baku] from bug 1604212 comment #0)

Chrome is enabling samesite=lax by default. This bug is about enabling the same feature in firefox.

Do we know if they've shipped this to release / what issues they've had with salesforce? Do we have a plan to turn this back off in nightly or a way of addressing the issues it's causing?

Flags: needinfo?(amarchesini)

Do we know if they've shipped this to release / what issues they've had with salesforce? Do we have a plan to turn this back off in nightly or a way of addressing the issues it's causing?

Chrome has enabled "sameSite=lax by default" for 25% of their population, as far as I know.
Our plan is to monitor the breakage in nightly and be ready to enable the same feature when Chrome goes close to 100%.

At the moment, what we do is to contact the websites asking to fix the issue. Here, there are several fixes to do. The easiest one is to pass sameSite=none. But maybe they should check if they need a cookie policy so open.

Flags: needinfo?(amarchesini)
Priority: -- → P3
Whiteboard: [necko-triaged]
No longer depends on: sameSiteLax-breakage

Just FYI that I have retested in 77.0a1 (2020-04-14) (64-bit) and the problem is still there until I toggle network.cookie.sameSite.laxByDefault to false.

We tried raising the problem with Salesforce, but they close our ticket saying that they only support Firefox Release.

I assume you are all aware that Chrome delayed enabling samesite=lax by default.
https://blog.chromium.org/2020/04/temporarily-rolling-back-samesite.html

I've asked our CCADB Salesforce admin to make the two changes described here:
https://releasenotes.docs.salesforce.com/en-us/spring20/release-notes/rn_general_chrome_samesite.htm

  1. To require HTTPS access in communities, portals, or sites:
    From Setup, enter Sites in the Quick Find box, then select Sites.
    Click the site you want to edit, and ensure that the Require Secure Connections (HTTPS) checkbox is selected.
  2. update the SameSite attribute on cookies used for cross-domain communication to explicitly set SameSite=None; Secure
    and
    When you set a cookie in Apex, use the new SameSite attribute of the Cookie() constructor method.

I'll re-test with Firefox Nightly when those changes have been made.

Either Salesforce has done something special to resolve this samesite problem on Chrome, or Firefox is implementing it differently...

The problems are there in Firefox Nightly, Beta, and Release when I set network.cookie.sameSite.laxByDefault to true, and the problems go away when I toggle it back to false.

But I installed Chrome 81 to test this out, and made sure I had the "SameSite by default cookies" and "Cookies without SameSite must be secure" experiments enabled, and restarted Chrome, and I am not able to reproduce the problems.

It would be really great if someone from Mozilla can reach out to Salesforce about this, and find out what is going on.
(We've tried, but they just close our support tickets as us using a non-supported Firefox configuration.)

(In reply to Kathleen Wilson from comment #12)

Either Salesforce has done something special to resolve this samesite problem on Chrome, or Firefox is implementing it differently...

The problems are there in Firefox Nightly, Beta, and Release when I set network.cookie.sameSite.laxByDefault to true, and the problems go away when I toggle it back to false.

But I installed Chrome 81 to test this out, and made sure I had the "SameSite by default cookies" and "Cookies without SameSite must be secure" experiments enabled, and restarted Chrome, and I am not able to reproduce the problems.

It would be really great if someone from Mozilla can reach out to Salesforce about this, and find out what is going on.
(We've tried, but they just close our support tickets as us using a non-supported Firefox configuration.)

Baku, do you know who would be the right person to do this?

Flags: needinfo?(amarchesini)

I can work on this. But I would like to know how to reproduce the issue. Can you provide an STR?

Either Salesforce has done something special to resolve this samesite problem on Chrome, or Firefox is implementing it differently...

We have several tests to see that chrome and firefox implementations are in sync, but we can have bugs, of course. If you can tell me how I can test it, I'm happy to provide a fix.

Flags: needinfo?(amarchesini) → needinfo?(kwilson)

(In reply to Andrea Marchesini [:baku] from comment #14)

I can work on this. But I would like to know how to reproduce the issue. Can you provide an STR?

We have issued you a read-only license to CCADB Sandbox, and you should have received an email about how to login. Please check your email (and SPAM folder) for it, and let me know if you have not received the email or if you have any questions.

Login via https://test.salesforce.com/

To see the problems:

  1. Click on the 'CA Owners/Certificates' tab, and select 'All CA Owners' then 'Go!'
    Click on "A-Trust" (or any CA), then scroll down to the "Account Hierarchy" section. It's supposed to show the CA's hierarchy, but currently in nightly it shows the home page instead.

  2. Click on the 'Cases' tab, and select 'All Open Cases' then 'Go!'
    Click on '01000001' (or any Case number). The 'Case Progress' section is supposed to have a progress bar, and the 'Messages' section is supposed to either have some text or be blank. Currently those sections show the home page instead.

Flags: needinfo?(kwilson)
Flags: needinfo?(amarchesini)

Thanks for the testing environment!

It seems that the cause is this function:

doesBrowserDefaultToSameSiteLax:function(b){b=b||g.userAgent;var a=b.chromeVersionMajor;return!!((b.isChrome||b.isChromium)&&77<=a)}}}(Sfdc));

I would remove this function entirely or I add the support for firefox too.

Flags: needinfo?(amarchesini) → needinfo?(kwilson)

(In reply to Andrea Marchesini [:baku] from comment #16)

Thanks for the testing environment!

It seems that the cause is this function:

doesBrowserDefaultToSameSiteLax:function(b){b=b||g.userAgent;var a=b.chromeVersionMajor;return!!((b.isChrome||b.isChromium)&&77<=a)}}}(Sfdc));

I would remove this function entirely or I add the support for firefox too.

Thank you Andrea for tracking this down.

So now the question for everyone: Is there someone at Mozilla who can contact Salesforce to request that they extend their SameSiteLax code to Firefox, because Firefox is also implementing these cookie protections?

Actually, Salesforce really should extend their SameSiteLax code to work on all browsers. They shouldn't need browser-specific code for this.

Flags: needinfo?(kwilson)

Peter, do you think you can help to contact salesforce folks?

Flags: needinfo?(stpeter)
See Also: → 1647854

I've reached out to a contact at Salesforce about this!

Flags: needinfo?(stpeter)

Changing the priority to p2 as the bug is tracked by a release manager for the current nightly.
See What Do You Triage for more information

Priority: P3 → P2

Peter, did you get an answer from your contact at Salesforce about it? Thanks

Flags: needinfo?(stpeter)

Not yet. I've followed up again.

Flags: needinfo?(stpeter)

Our contact at Salesforce reports that they are working on it and will release fixes before Fx 82.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: