Facebook infinite reloading page with image/user posts! Topic is solved

[GMforker]

Ad http://hg.mozilla.org/mozilla-central/p ... a157f7feb7

See #869

An example:
viewtopic.php?f=29&t=13005&start=40#p95079

The unstable versions:
1) ...from the master branch
2) ...from the master branch + after the following fixes

1) The page infinitely loads.
2) The same page will load without a problem.

Could it be that "CORS" is the same issue? But maybe it's a coincidence

[JustOff]

Could it be that "CORS" is the same issue? But maybe it's a coincidence

I can confirm that reload no longer occurs here and there after #869 was applied. It seems you have got it!

[Moonchild]

OK, I have to thank you VERY much for, by chance, finding the seemingly completely unrelated cause. This is a perfect example of "we need to know what trips up your code" and crickets as a response not helping.

I've merged the CORS change in and I'll build a new unstable today. if that confirms to fix it, I'll uplift it for 27.1 (since I still have to wait for Mozilla Security to give me sec bug access for FF51 bugs, anyway) -- at the same time I'll make the UA override native so there will be a solid record on FB's side of our users, as well as them being able to target that native UA directly if they are actually willing to fix things.

EDIT: new unstable is up. I checked the links and no infinite reloading occurs -- it still reloads once though, so there's certainly some scripting oddity still left on Facebook's side. if other on the unstable channel can confirm facebook operation if they previously had issues, I'll uplift.

[kizo07]

It seems you have got it

Yeah GMforker!
That's a good bargain! A satisfied customer is the best business strategy of all!

[JodyThornton]

So after all of this, are we saying it was Gecko related code? And by the way Tobin, I referenced you saying what you did before (except I didn't remember it was you saying it).

It occurred to me all along that there was some revision of Gecko where it took place. I'm glad you've seemed to have found it.

[back2themoon]

Could it be that "CORS" is the same issue? But maybe it's a coincidence

I can confirm that reload no longer occurs here and there after #869 was applied. It seems you have got it!

Thanks guys for your perseverance! Since the above two links do not reload any more here already (27.0.3), can you also try this one which still keeps reloading?

[JustOff]

I've merged the CORS change in and I'll build a new unstable today. if that confirms to fix it, I'll uplift it for 27.1 [..] at the same time I'll make the UA override native so there will be a solid record on FB's side of our users, as well as them being able to target that native UA directly if they are actually willing to fix things.

May be it's better to make unstable for public test without UA override, with only CORS changes? You do it faster than I write comments

can you also try this one which still keeps reloading?

Nope. Even in FF compatibility mode all is ok.

UPD: New unstable build is already published, you can check it yourself.

[JodyThornton]

I had already narrowed it down... Does no one read or remember what I say anymore unless it offends them?

But maybe that should tell you something Matt A Tobin. Perhaps (and I say this working in broadcasting) the delivery is every bit as important as the message.
And I do recall you saying what you did, but I had completely forgotten it was you. I knew someone said the refreshes stopped somewhere along the line. So my thought was, "why aren't you guys feverishly looking for it???" I think I posted to that effect.

[Moonchild]

So after all of this, are we saying it was Gecko related code? And by the way Tobin, I referenced you saying what you did before (except I didn't remember it was you saying it).

It occurred to me all along that there was some revision of Gecko where it took place. I'm glad you've seemed to have found it.

It's Gecko-adopted code, but the thing is, I checked the specs involved and nowhere does it say that data: URIs should be treated as same-origin in CORS. (I checked both the HTML spec and the CORS Fetch spec).
So although logical that data: is considered same-origin by the mainstream browsers, it's not in the spec, and was changed in Gecko because Chrome+IE do this.

Allowing this does make data: injection a potential attack surface.

Ultimately, it's still Facebook's issue specifying a CORS attribute on something with a data: URI as source and then tripping over their own unspecified usage with a security check when it's denied by Pale Moon. But certainly there's no reason why in the common case this should not be allowed.

[JodyThornton]

I've merged the CORS change in and I'll build a new unstable today. if that confirms to fix it, I'll uplift it for 27.1 [..] at the same time I'll make the UA override native so there will be a solid record on FB's side of our users, as well as them being able to target that native UA directly if they are actually willing to fix things.

May be it's better to make unstable for public test without UA override, with only CORS changes?

can you also try this one which still keeps reloading?

Nope. Even in FF compatibility mode all is ok.

So this is on the unstable release?

[Moonchild]

So this is on the unstable release?

See above.
New unstables are up with the CORS change (but not the SSUAO yet)

[back2themoon]

Did some quick tests with the unstable and indeed everything works perfectly, and Facebook runs generally smoother (tested with the native string). The below 'issue' has been fixed, too. Thanks again, everyone.

About Messenger, I'm seeing this small difference from other browsers (incl.FF): when switching between users (on the left column), the whole page is being "refreshed" instead of just the message content so this adds some inevitable delay. Minor issue though and it otherwise works fine.

[Moonchild]

FTR: the following report was sent to Facebook:

Dear support team:

Well, we've finally figured out what your problem is with triggering constant reloads, no thanks to your lack of help or willingness to do anything about it.
I do hope you forward the following technical details to your back-end developers because it is an important problem:

Apparently, you are using CORS restrictions on theater mode/gallery pages (or potentially all photos). Adjunct to that you use data: URIs in the same elements. The HTML and CORS Fetch specs don't specify how to treat data: URIs in this situation and secure browsers would deny these requests because it would present a potential attack surface for injection (injecting base64 data could in-line replace element contents by changing the src attribute).
If such a request is denied on the browser side, your website code goes into a reload loop (gallery->theater->gallery-> etc. ad nauseum) making further use of Facebook impossible. Mainstream browsers like Chrome are not considering the relevant attack surface and as such do not run into this problem. Our browser attempts to enforce stricter, in-spec, security, and as such hits this webdesign issue.

Please consider checking and changing the relevant code.

Moonchild,
Pale Moon lead dev.

I do plan to put this behind a pref eventually, because users should have the choice to deny potentially insecure loads from data: URIs if CORS is specified on the element.
Looking a bit more into this, making this pref-controlled is going a bit too far. The default allowance is fine; if you have a problem with data injection, then the only additional way this could be a problem is if you already have injection mitigation in place that doesn't understand base64.

[wildbill5891]

It is a Pale Moon issue, because it doesn't happen when I use CyberFox or Firefox 64bit.

[back2themoon]

It is a Pale Moon issue, because it doesn't happen when I use CyberFox or Firefox 64bit.

Sounding so convinced (following a thread with extensive discussion on this), I'm guessing you've also researched on the underlying technical issues of Facebook-Pale Moon communication in order to reach this conclusion... right?

[half-moon]

It is a Pale Moon issue, because it doesn't happen when I use CyberFox or Firefox 64bit.

It's been proven time and time again that it's a facebook issue.

FTR: the following report was sent to Facebook:

Dear support team:

Well, we've finally figured out what your problem is with triggering constant reloads, no thanks to your lack of help or willingness to do anything about it.
I do hope you forward the following technical details to your back-end developers because it is an important problem:

Apparently, you are using CORS restrictions on theater mode/gallery pages (or potentially all photos). Adjunct to that you use data: URIs in the same elements. The HTML and CORS Fetch specs don't specify how to treat data: URIs in this situation and secure browsers would deny these requests because it would present a potential attack surface for injection (injecting base64 data could in-line replace element contents by changing the src attribute).
If such a request is denied on the browser side, your website code goes into a reload loop (gallery->theater->gallery-> etc. ad nauseum) making further use of Facebook impossible. Mainstream browsers like Chrome are not considering the relevant attack surface and as such do not run into this problem. Our browser attempts to enforce stricter, in-spec, security, and as such hits this webdesign issue.

Please consider checking and changing the relevant code.

Moonchild,
Pale Moon lead dev.

I do plan to put this behind a pref eventually, because users should have the choice to deny potentially insecure loads from data: URIs if CORS is specified on the element.
Looking a bit more into this, making this pref-controlled is going a bit too far. The default allowance is fine; if you have a problem with data injection, then the only additional way this could be a problem is if you already have injection mitigation in place that doesn't understand base64.

It does seem the way facebook coded their site is completely irresponsible.

[snertev]

OK, I have to thank you VERY much for, by chance, finding the seemingly completely unrelated cause. This is a perfect example of "we need to know what trips up your code" and crickets as a response not helping.

I've merged the CORS change in and I'll build a new unstable today. if that confirms to fix it, I'll uplift it for 27.1 (since I still have to wait for Mozilla Security to give me sec bug access for FF51 bugs, anyway) -- at the same time I'll make the UA override native so there will be a solid record on FB's side of our users, as well as them being able to target that native UA directly if they are actually willing to fix things.

Please, pay attention that by using the native UA tagging people on Facebook doesn't work.

Or, at least, it didn't work last time I checked it while testing UAs for this issue.

Edit: it didn't work with a 64 bit UA.

[BenFenner]

Posting to follow up after updating a couple of our computers to PM 27.1 (too lazy to do the living room and bed room right now)

Pages/images confirmed to loop just moments before upgrading are fixed on both machines now. Great sleuthing! Woohoo!

[Moonraker]

It is a Pale Moon issue, because it doesn't happen when I use CyberFox or Firefox 64bit.

The pale moon developer has explained why it is not a palemoon issue.
FTR:facebook is working perfectly now after update.

[kizo07]

Although 27.03. worked as a charm here, even on the Facebook, 27.1 works even better.
Photos are even better too. But, unless FB friends sends me some naked photos I'm not much interested in them anyway.

Otherwise, I seems that there are plenty of monkeys on Facebook. Maybe, as pure business proposal, should change name to MonkeyBook?
Huh, as usually, my friends do nothing there, exept complaing, so I'm bit afraid that they wouldn't say 'Mind your own business'.