1672233 - Our members are unable to connect to our website since the last version 82.0 It's the same problem as on one of the previous versions!

Status: RESOLVED INCOMPLETE

(Core :: DOM: Core & HTML, defect)

Description

[Walter]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

Our members are unable to connect to our website since the last version 82.0 It's the same problem as on one of the previous versions! Members remain on the home page of our site. Refreshing the page will load the rest.

Actual results:

Members blocked on the home page after login

Expected results:

The page of the site after connection should load normally.

Comment 1

[Marcela (Please NI request to Brindusa Tot)]

Hi Walter!
Please could you add some test cases or more exact steps or the Website URL to test this issue? Also, you can try to reproduce this problem on latest Nightly, download it from here: https://nightly.mozilla.org/

Comment 2

[Walter]

https://demo.wowonder.com/
Open an account here and try to login on this script. You'll see. Once connected, the page must be refreshed to go further. On Chrome and Opera, there is no problem but on Firefox, it blocks! This bug has already been resolved after version 81 and then now in version 82.

Comment 3

[Marcela (Please NI request to Brindusa Tot)]

Hi,
Thank you for your reply. I was able to reproduce it on latest Nightly version 84.0a1 (2020-10-30)(64-bit) on Windows 10. After refreshing the page the webpage was loaded completely. I will attach a file with web console information.
I will set a component, please If you consider that there's another component that's more proper for this case you may change it.

Comment 4

[Marcela (Please NI request to Brindusa Tot)]

Attachment: bug 1672233.png

Comment 5

[Marcela (Please NI request to Brindusa Tot)]

The suggested severity revolves around S3 since the action can be finished after the refresh is done.

Comment 6

[Edouard Oger [:eoger]]

Not sync related

Comment 7

[Marcela (Please NI request to Brindusa Tot)]

I'll set a component, please If you consider that there's another component that's more proper for this case you may change it.

Comment 8

[Edgar Chen [:edgar]]

(In reply to Walter from comment #0)

Our members are unable to connect to our website since the last version 82.0 It's the same problem as on one of the previous versions! Members remain on the home page of our site. Refreshing the page will load the rest.

Seems like a regression? Marcela, could you try to find the regression window? Thanks!

Comment 9

[Marcela (Please NI request to Brindusa Tot)]

Regression window:
Bisecting on mozilla central (2020-09-16 - 2020-10-22)
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8ae706cfee33871aadf9c4aaa3d6480dafed07be&tochange=573659457e9c755806b3503803c05f45871fbab7

Comment 10

[Emilio Cobos Álvarez (:emilio)]

Bug 1668577 claims to be in the 83 branch, but comment 0 says this regression happens in 82...

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

bug 1668577 should change behavior in Fission only.
But let me test.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

I can reproduce the behavior in a built just before bug 1668577 .

Comment 13

[Walter]

Hello ! For information, this bug is still not resolved in the latest version 82.0.3 . It's very long and our customers are starting to get impatient that they can't use Firefox on this script that we sell. You corrected it following version 81, why this problem which is not present on Chrome or Opera? cordially

Comment 14

[Emilio Cobos Álvarez (:emilio)]

In the console, there is a warning when you try to login:

Cookie “user_id” has been rejected because it is already expired.

How is that cookie getting set?

Comment 15

[Emilio Cobos Álvarez (:emilio)]

(I can try to poke, but the above may help)

Comment 16

[Emilio Cobos Álvarez (:emilio)]

My bisect points to bug 1649807: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=5c22eb861a6340c52dd5be4077784625cb3e60eb&tochange=65e6c73de900d697b3720c5d11408636d5f62635

Comment 17

[Emilio Cobos Álvarez (:emilio)]

So I think this is invalid, you're sending the following in the http response:

Cache-Control: max-age=846000
Pragma: no-cache

Those are conflicting instructions. Firefox is choosing to honor the modern Cache-Control header, and Chromium is honoring the Pragma one.

So I think this is a server misconfiguration. Do you agree?

Comment 18

[Emilio Cobos Álvarez (:emilio)]

See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Pragma:

Note: Pragma is not specified for HTTP responses and is therefore not a reliable replacement for the general HTTP/1.1 Cache-Control header, although it does behave the same as Cache-Control: no-cache, if the Cache-Control header field is omitted in a request. Use Pragma only for backwards compatibility with HTTP/1.0 clients.

Comment 19

[Emilio Cobos Álvarez (:emilio)]

Something like this of course "fixes" it:

diff --git a/netwerk/protocol/http/nsHttpResponseHead.h b/netwerk/protocol/http/nsHttpResponseHead.h
index 4126acd13398..75c3d1500a36 100644
--- a/netwerk/protocol/http/nsHttpResponseHead.h
+++ b/netwerk/protocol/http/nsHttpResponseHead.h
@@ -194,9 +194,8 @@ class nsHttpResponseHead {
   }
 
   bool NoCache_locked() const {
-    // We ignore Pragma: no-cache if Cache-Control is set.
     MOZ_ASSERT_IF(mCacheControlNoCache, mHasCacheControl);
-    return mHasCacheControl ? mCacheControlNoCache : mPragmaNoCache;
+    return mCacheControlNoCache || mPragmaNoCache;
   }
 
  private:

But I don't think we should do that given the comment 18 and that we only know of this affected website.

Comment 20

[Walter]

The server is perfectly well adjusted. Everything worked perfectly before. This bug has already been corrected after version 81.0 and before that in previous versions this bug has already been identified and then corrected. The script designer has sold thousands of scripts and all of them have the same problem, which obviously has nothing to do with server tuning. For your information, more than 5,000 commercialized sites are in this situation. Comments are posted here and the developer's response is indeed a bug to report at Mozilla. Cordially. https://codecanyon.net/item/wowonder-the-ultimate-php-social-network-platform/13785302

Comment 21

[Jens Stutte [:jstutte]]

Hi Walter,
can you check if the php files in question contain only something like

header("Pragma: no-cache");

and not also

header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");
header("Cache-Control: post-check=0, pre-check=0", false);
header("Pragma: no-cache");

or similar? Then the software you are running on your server is not setting the headers in the expected way, assuming that you use the default settings for caching. So technically your server might be perfectly well adjusted but still send the wrong headers. In that case probably a bug should be filed against wowonder. Thank you

Comment 22

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

Changing severity to S3 because of comment 18, 19 and 21 that this is more likely due to sever configuration. Once we get the final confirmation from reporter, we may close this as invalid.

Comment 23

[Jens Stutte [:jstutte]]

Closing as there has been no response for two years. It would have been nice to have a confirmation from the reporter, but in case you still think there is a problem on our side, feel free to re-open or file a new bug.