FF75.0a1: Visualforce pages embedded in Salesforce standard page failing in Nightly
Categories
(Core :: Networking: Cookies, defect, P2)
Tracking
()
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.
Reporter | ||
Comment 1•4 years ago
|
||
Attaching the program files so that you can see the code behind the two embedded components.
Reporter | ||
Comment 2•4 years ago
|
||
Comment 3•4 years ago
|
||
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.
Comment 4•4 years ago
|
||
Oh, and is this perhaps fixed if you toggle network.cookie.sameSite.laxByDefault
to false
in about:config ?
Reporter | ||
Comment 5•4 years ago
|
||
(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
tofalse
in about:config ?
Yes, that fixes the problem. Thanks!
Should I close this bug as WORKSFORME?
Comment 6•4 years ago
|
||
(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
tofalse
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.
Updated•4 years ago
|
Reporter | ||
Comment 7•4 years ago
|
||
(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/
Updated•4 years ago
|
Updated•4 years ago
|
Comment 8•4 years ago
|
||
(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?
Comment 9•4 years ago
|
||
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.
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 10•4 years ago
|
||
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.
Updated•4 years ago
|
Updated•4 years ago
|
Reporter | ||
Comment 11•4 years ago
|
||
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
- 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. - 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.
Reporter | ||
Comment 12•4 years ago
|
||
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.)
Comment 13•4 years ago
|
||
(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?
Comment 14•4 years ago
|
||
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.
Reporter | ||
Comment 15•4 years ago
|
||
(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:
-
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. -
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.
Reporter | ||
Updated•4 years ago
|
Comment 16•4 years ago
|
||
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.
Reporter | ||
Comment 17•4 years ago
|
||
(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.
Comment 18•4 years ago
|
||
Peter, do you think you can help to contact salesforce folks?
Comment 19•4 years ago
|
||
I've reached out to a contact at Salesforce about this!
Updated•4 years ago
|
Comment 21•4 years ago
|
||
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
Comment 22•4 years ago
|
||
Peter, did you get an answer from your contact at Salesforce about it? Thanks
Comment 24•4 years ago
|
||
Our contact at Salesforce reports that they are working on it and will release fixes before Fx 82.
Updated•4 years ago
|
Reporter | ||
Updated•3 years ago
|
Description
•