Poor rendering of pages on GitHub
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
People
(Reporter: psychonaut, Unassigned)
Details
Attachments
(4 files)
SeaMonkey 2.53.3 has problems rendering certain pages and page elements on GitHub. The problems did not occur when I was using SeaMonkey 2.53.2 (though I suppose it is possible that GitHub updated its UI at about the same time that 2.53.3 was released).
Examples of rendering problems:
-
Most of the issue search results page are completely scrambled. See https://github.com/logological/gpp/issues?q=is%3Aissue+is%3Aopen+master as an example. The attached screenshots show the problematic rendering in SeaMonkey 2.53.2 and correct rendering in Firefox 78.0.2.
-
On any GitHub form that allows you to enter Markdown and to preview it in a separate tab, the preview tab always shows an "Error rendering preview" message. See https://github.com/logological/gpp/issues/new for an example (but note that this page can be viewed only if you are logged into a GitHub account). The attached screenshots show the problematic rendering in SeaMonkey 2.53.2 and correct rendering in Firefox 78.0.2.
Reporter | ||
Comment 1•5 years ago
|
||
Reporter | ||
Comment 2•5 years ago
|
||
Reporter | ||
Comment 3•5 years ago
|
||
Reporter | ||
Comment 4•5 years ago
|
||
![]() |
||
Comment 5•5 years ago
|
||
They are rolling out Custom Elements and have some sort of polyfill in place. Also the last time I complained they told me they do not support SeaMonkey. I thanked them and worte "no problem gitlab works". Didn't hear back :) Using Chromium Edge for their junk pages.
Filing web compatibility bugs like this one is more or less not going anwhere. We try to backport as much as possible until 2.57 is ready and unless you have a specific bug number or missing feature what is needed it is just one unspecifc bug more.
Reporter | ||
Comment 6•5 years ago
|
||
(In reply to Frank-Rainer Grahl (:frg) from comment #5)
unless you have a specific bug number or missing feature what is needed it is just one unspecifc bug more.
Sorry, I didn't realize that these reports may be unwanted. I have recently seen others—usually but not always Rainer Bielefeld—posting compatibility bugs for specific (but popular) websites using a similar level of detail (i.e., giving enough instructions to reproduce the problem, but not identifying the specific page elements that may be the root cause). If this isn't helpful—not even as a starting point for others with more time and knowledge to narrow down the missing feature—then I can refrain from filing such issues in the future.
![]() |
||
Comment 7•5 years ago
|
||
Not exactly unwanted but I can file compatibility bugs all day and they will go nowhere. I have seen Rainers reports and they fall in the same category.
It is unfortunate but it is how it is. We really try... Just wanted to let you know. If I file a bug I have at least the expectation this it is quickly sorted out and at least categorized. With these unspecific bugs not pointing to a specific missing feature and with websites pushing a ton of obfuscated javascript and more junk this is unfortunately not possible with the existing dev resources / time.
(In reply to Tristan Miller from comment #0)
SeaMonkey 2.53.3 has problems rendering certain pages and page elements on GitHub. The problems did not occur when I was using SeaMonkey 2.53.2 (though I suppose it is possible that GitHub updated its UI at about the same time that 2.53.3 was released).
Examples of rendering problems:
Most of the issue search results page are completely scrambled. See https://github.com/logological/gpp/issues?q=is%3Aissue+is%3Aopen+master as an example. The attached screenshots show the problematic rendering in SeaMonkey 2.53.2 and correct rendering in Firefox 78.0.2.
On any GitHub form that allows you to enter Markdown and to preview it in a separate tab, the preview tab always shows an "Error rendering preview" message. See https://github.com/logological/gpp/issues/new for an example (but note that this page can be viewed only if you are logged into a GitHub account). The attached screenshots show the problematic rendering in SeaMonkey 2.53.2 and correct rendering in Firefox 78.0.2.
Hi, you mention 2.53.3 to start with then go on to compare 2.53.2. Is it happening in both now?
Reporter | ||
Comment 9•5 years ago
|
||
(In reply to Ian Neal from comment #8)
Hi, you mention 2.53.3 to start with then go on to compare 2.53.2. Is it happening in both now?
Sorry, the instances of "2.53.2" in my examples were typos (or rather, one typo that got copied and pasted). I had meant to write "2.53.3".
But I did try both examples just now in both 2.53.2 and 2.53.3. Results:
I cannot reproduce the behaviour of Example 1 in either version. I guess whatever changes GitHub recently rolled out to the issue search results page have been modified in the past few hours such that they now work properly in SeaMonkey.
I can reproduce the behaviour of Example 2 in both versions. So the problem isn't something that is new in SeaMonkey 2.53.3.
![]() |
||
Comment 10•5 years ago
|
||
Anything in the error console when you try Markdown?
Reporter | ||
Comment 11•5 years ago
|
||
Starting from a fresh profile and in safe mode, there are about 200 warnings when I load the issue page at https://github.com/logological/gpp/issues/new, but only one error:
Timestamp: 7/27/20, 11:01:49 PM GMT+2
Error: Content Security Policy: The page’s settings blocked the loading of a resource at https://github.com/socket-worker.js (“default-src 'none'”).
Nothing further gets printed to the error console when I type into the Markdown text area or click on the Preview tab.
If you want the text of the warning messages, please let me know how I can best save them all, as I don't see any obvious way of copying more than one at a time to the clipboard.
Reporter | ||
Comment 12•5 years ago
|
||
(In reply to Tristan Miller from comment #9)
I cannot reproduce the behaviour of Example 1 in either version. I guess whatever changes GitHub recently rolled out to the issue search results page have been modified in the past few hours such that they now work properly in SeaMonkey.
Further testing shows that the example is reproducible, but only the first time a given search query is returned. If I reload the page, then everything looks fine. From comparing the HTML of the original results page and the reloaded version, it looks like the HTML is substantially different. And the original results contains the following message at the bottom of the source file (which I had never noticed before as it doesn't get rendered):
What‽
Your browser did something unexpected. Please contact us if the problem persists.
Alas, the message doesn't indicate how to contact them, and there's no obvious way of doing so from their "Contact Us" page at https://support.github.com/request. That page seems to be designed to divert all bug reports to their community forums, where no one with the power to actually fix the problem will ever see them.
![]() |
||
Comment 13•5 years ago
|
||
You can try setting
dom.serviceWorkers.enabled
dom.moduleScripts.enabled
This might help on some pages. Both options arre still problematic. A lot of fixes are already in but we will leave them disabled until the last known crasher is fixed.
Reporter | ||
Comment 14•4 years ago
|
||
(In reply to Frank-Rainer Grahl (:frg) from comment #5)
They are rolling out Custom Elements and have some sort of polyfill in place. Also the last time I complained they told me they do not support SeaMonkey. I thanked them and worte "no problem gitlab works".
Not anymore! As you yourself noted in Bug 1731832 Comment 4, GitLab no longer works with SeaMonkey.
That same comment indicates that the problem with GitLab can be worked around by installing the GitHub/GitLab Web Components Polyfill add-on. It seems that the same add-on fixes the remaining GitHub issue reported here, so I assume that I can close this bug with the same resolution as Bug 1731832. However, I lack the rights to mark this as RESOLVED/INCOMPLETE so perhaps you could do so yourself.
![]() |
||
Comment 15•4 years ago
|
||
I suspect by the time we support Custom Elements they will roll out another must have toy. Maybe animated inclusive emoticons using experimental api 2025 v0.001b1 :)
Updated•4 months ago
|
Description
•