INSTAGRAM and FACEBOOK contents "not available"
Categories
(SeaMonkey :: Web Compatibility, defect)
Tracking
(Not tracked)
People
(Reporter: RainerBielefeldNG, Unassigned)
References
()
Details
(Keywords: regression, Whiteboard: [easyconfirm])
User Story
WORKAROUND: User Agent String like Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 SeaMonkey/2.53.16 (without "Firefox ..., but with "SeaMonkey/2.53.16 ", which has been dropped.) For example using Add-On "User Agent Switcher" Not yet tested enough for negative effects on other pages
Attachments
(3 files)
Screenshot
STR with installation of de SeaMonkey 2.53.16 Beta 1 Pre Mozilla/5.0 (NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 Build 20221208220001 (Same with normal user Profile and newly created User Profile Default Classic Theme) on German WIN10 64bit:
- visit https://www.instagram.com/
» Expected: contents shown
Actual: Message "Page is not available"
|
Reporter | |
Comment 1•2 years ago
|
||
Error Console shows lots of warnings, but no error
|
|
Reporter | |
Comment 2•2 years ago
•
|
||
Regression compared to 2.53.14:
11. Create and use new User Profile in 2.53.16B1
12. Close SeaMonkey, launch SM 2.53.14 with newly created User Profile
13. Visit https://www.instagram.com/ → Login
» Page shown with normal contents 👌
14. Close WM
15. Launch 2.53.16 Beta 1 Pre with newly created User Profile
» Error Message as per (1) 😥
So regression with 2.53.16 (two dom.webcomponents values enabled or disabled doesn't matter)
|
|
Reporter | |
Updated•2 years ago
|
|
|
Reporter | |
Comment 3•2 years ago
|
||
More or less the same regression with facebook.com:
Error Message is a little different, but all other test results same.
|
|
Reporter | |
Updated•2 years ago
|
|
||
Comment 4•2 years ago
|
||
Instagram is possibly serving/fetching a different script file when visited with the User-Agent of a newer Firefox. One difference I saw so far was that POST requests for https://www.instagram.com/ajax/bulk-route-definitions/ result in 5xx errors with the newer Firefox version, and lack the "routing_namespace" parameter, which is present when these requests succeed. Might be just a coincidence, though.
|
||
Comment 5•2 years ago
|
||
Works if you set the ua to SeaMonkey only. 2.53.15 switched to setting base ua to 91 and these two seem to not like it and serve incorrect or later syntax content. A ton of others now work again so can't backout this change in SeaMonkey.
|
|
Reporter | |
Updated•2 years ago
|
|
|
Reporter | |
Updated•2 years ago
|
Can you confirm setting useragent to seamonkey solves the issue? I had to roll back the update for now.
|
||
Comment 9•2 years ago
|
||
I can confirm that setting the user-agent to SeaMonkey only (without advertising Firefox compatibility) works around this issue on Facebook. Unfortunately, using a user-agent string that doesn't advertise Firefox compatibility breaks other websites—see for example Bug 1797048.
|
|
Reporter | |
Comment 10•1 year ago
|
||
Workaround still necessary with ZIP of en-US SeaMonkey 2.53.18 Beta 1 Pre Mozilla/5.0 (NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0 SeaMonkey/2.53.18 Build 20230707110003 (normal user Profile and newly created User Profile), Default Classic Theme on German WIN10 64bit
|
|
Reporter | |
Comment 11•1 year ago
|
||
Well known problem.
|
||
Comment 12•1 year ago
|
||
(In reply to Tristan Miller from comment #9)
I can confirm that setting the user-agent to SeaMonkey only (without advertising Firefox compatibility) works around this issue on Facebook. Unfortunately, using a user-agent string that doesn't advertise Firefox compatibility breaks other websites—see for example Bug 1797048.
this can be done on a per website base:
general.useragent.override.instagram.com as a string, and the original user agent string, minus the firefox-91 compability string of course
|
||
Updated•1 year ago
|
Description
•