Washington Post web site reader comments no longer display
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox66 | --- | affected |
| firefox67 | --- | unaffected |
| firefox68 | --- | unaffected |
People
(Reporter: reai5918, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0
Steps to reproduce:
Visit any article in Washington Post web site that has reader comments enabled. Click on the reader comments link that is offered below the article (e.g. "398 comments") in order to see the comments.
Note, using latest version of Firefox for Windows with NoScript. Happens even if NoScript is disabled. Downloaded and installed latest Firefox late on May 12th, 2019 U.S. Mountain Time zone. 66.0.5 (64-bit)
Actual results:
The web page now displays "Posting as <my name>" but no further text appears. Screen is blank below "Posting as ..." In the Google Chrome browser this works properly.
Expected results:
Should see reader comments about the article, and a dialog box in which to enter one's own comments about the article.
|
||
Updated•5 years ago
|
|
||
Updated•5 years ago
|
|
||
Comment 1•5 years ago
•
|
||
Hi,
i've managed to reproduce this issue on the latest release (66.0.5) but not on nightly(68.0a1 5-14-2019) or beta(67.0b19). I will also assign a component but feel free to change it if you consider it wrong.
Regards
|
|
||
Updated•5 years ago
|
|
|
||
Updated•5 years ago
|
|
||
Comment 2•5 years ago
|
||
Could you find a fix range or such with mozregression --bad 66 --find-fix? Otherwise assigning it to layout is pretty random.
|
|
||
Updated•5 years ago
|
|
|
||
Comment 3•5 years ago
|
||
Hi Emilio, ok i will provide the range as soon as possible
Best regards
|
|
||
Comment 4•5 years ago
|
||
Hi again,
here is the mozregression output for the command "mozregression --bad 2019-01-01 --good 2019-05-14 --find-fix"
79:35.54 INFO: First good revision: 4abfd3bb993421ad8132d3cbde909c8a6c03ec6f
79:35.54 INFO: Last bad revision: 7d289fe21aecd01d80482a92b95c4000c761a7b8
79:35.54 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7d289fe21aecd01d80482a92b95c4000c761a7b8&tochange=4abfd3bb993421ad8132d3cbde909c8a6c03ec6f
Hope helps
David
|
|
||
Comment 5•5 years ago
|
||
(In reply to David Sacal from comment #4)
Hi again,
here is the mozregression output for the command "mozregression --bad 2019-01-01 --good 2019-05-14 --find-fix"79:35.54 INFO: First good revision: 4abfd3bb993421ad8132d3cbde909c8a6c03ec6f
79:35.54 INFO: Last bad revision: 7d289fe21aecd01d80482a92b95c4000c761a7b8
79:35.54 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=7d289fe21aecd01d80482a92b95c4000c761a7b8&tochange=4abfd3bb993421ad8132d3cbde909c8a6c03ec6fHope helps
David
|
|
||
Comment 6•5 years ago
|
||
Err, that was meant to be:
Thanks! Boris, is this something interesting to you? It's not clear to me bug 1471496 intended to be a behavior change.
|
||
Comment 7•5 years ago
|
||
Bug 1471496 was not supposed to be a behavior change, indeed. The behavior changes were in bug 1514050.
Looking into what's going on here.
|
|
||
Comment 8•5 years ago
•
|
||
I could use a specific test URL to use here, esp. since the Washington Post blocks me from loading its articles in my normal browsing profile.... :(
Here is the URL from Firefox after clicking the comments link, when it doesn't work. I think this is simply the link to the original article which "contains" the comment section.
Thanks
Roger (original poster)
|
|
||
Comment 10•5 years ago
|
||
Thank you!
If I load that link, scroll down to the button that says "696 Comments" and click that, I get a button that says "Sign in to join the conversation" and the comments show up below that. I see that behavior in a nightly from right before bug 1471496 was checked in.
That said, I do see the reported problem in Firefox 66 release. Let me see if I can find a regression range on this end....
|
|
||
Comment 11•5 years ago
•
|
||
I'm really not quite sure what's going on here at this point. It doesn't help that the site sometimes loads comments and sometimes not, even in the same build. :(
In bug 1471496 there were two changes: part 1 fixed a bug in whether MaybeCrossOriginObject considered itself cross-origin due to first-party isolation not really affecting script access, and part 2 started using MaybeCrossOriginObject for the same-origin case as well.
It's part 1 that fixes the Washington Post case as near as I can tell from bisecting. Before that changeset, when the comment display fails (which it doesn't do consistently; that made bisecting extra-fun), we get a security exception with this stack:
#01: js::ReportAccessDenied(JSContext*) (/home/bzbarsky/mozilla/vanilla/mozilla/js/src/proxy/Wrapper.cpp:466)
#02: js::AutoEnterPolicy::reportErrorIfExceptionIsNotPending(JSContext*, JS::Handle<JS::PropertyKey>) (/home/bzbarsky/mozilla/vanilla/mozilla/js/src/proxy/Proxy.cpp:40)
#03: AutoEnterPolicy (/home/bzbarsky/mozilla/vanilla/obj-firefox/js/src/../../dist/include/js/Proxy.h:616)
#04: js::Proxy::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) (/home/bzbarsky/mozilla/vanilla/mozilla/js/src/proxy/Proxy.cpp:500)
#05: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct) (/home/bzbarsky/mozilla/vanilla/obj-firefox/js/src/../../../mozilla/js/src/vm/Interpreter.cpp:508)
#06: InternalCall(JSContext*, js::AnyInvokeArgs const&) (/home/bzbarsky/mozilla/vanilla/obj-firefox/js/src/../../../mozilla/js/src/vm/Interpreter.cpp:589)
#07: js::CallFromStack(JSContext*, JS::CallArgs const&) (/home/bzbarsky/mozilla/vanilla/obj-firefox/js/src/../../../mozilla/js/src/vm/Interpreter.cpp:593)
#08: Interpret(JSContext*, js::RunState&) (/home/bzbarsky/mozilla/vanilla/obj-firefox/js/src/../../../mozilla/js/src/vm/Interpreter.cpp:3069)
and after it we do not.
That said, I tested what's going on in IsPlatformObjectSameOrigin() when we hit that exception, and both branches of the OriginAttributes::IsRestrictOpenerAccessForFPI() (if I compute them both in the changeset before I added the branch) return the same value. Which is not surprising, since the branches should only differ when first-party isolation is enabled, and for me the "privacy.firstparty.isolate" pref is set to "false"... So I really have no idea what's going on here now. :(
Also, when I try builds from before bug 1363208 was fixed I think I see the problem too... Again, hard to tell because the site is pretty flaky for me in terms of whether it shows the problem or not. I would have expected builds from before bug 1363208 to not have this problem, if bug 1471496 was involved in fixing it.
|
|
||
Comment 12•5 years ago
|
||
Alright, I just got the failure to load comments and the security exception several times in a row on part 1 of bug 1471496. So looks like the earlier bisect results for me were not right... I really wish the problem were not intermittent. :(
|
|
||
Comment 13•5 years ago
|
||
OK, I know what was going on here, and why bug 1471496 fixed it. Before bug 1471496 we have a transparent CCW to a window that's not same-origin-domain as us, for some complicated reasons, so getting a postMessage function from it gives us an opaque security wrapper and trying to call that throws and kills the script that's trying to show the comments. Having that transparent CCW is a bug; I filed bug 1552541 on that.
After bug 1471496, we always have a CrossOriginObjectWrapper; it detects that the caller and callee are not same-origin-domain when doing the get and and vends a new postMessage method for the caller in its compartment, which the caller can then call.
Description
•