error console flooded by "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”."
Categories
(Thunderbird :: General, defect, P3)
Tracking
(thunderbird_esr91 unaffected, thunderbird_esr102 wontfix)
Tracking | Status | |
---|---|---|
thunderbird_esr91 | --- | unaffected |
thunderbird_esr102 | --- | wontfix |
People
(Reporter: wsmwk, Assigned: mkmelin)
References
(Regression)
Details
(Keywords: regression)
Attachments
(4 files)
This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”.
On average a couple times a minute. Don't know when it started.
Assignee | ||
Comment 1•3 years ago
|
||
It's from bug 1238861
I'm still seeing this as of 101.0b4 on Windows 10 (64 bit)
This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”.
Inbox
This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”.
{71f0fd45-ab45-4d03-86f7-db293fb40947}
This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”.
blank
This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”.
Inbox
...
Comment 3•3 years ago
|
||
Also appears along with "This page is in Almost Standards Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”." in the latest 102.0a1.
As pointed out in comment 1 it is from bug 1238861, and if you click the Learn More link, you learn more.
Comment 4•3 years ago
•
|
||
During mochitest run of FULL DEBUG version of C-C TB, I get 3389 lines of similar warning lines from many tests.
3K+ lines are a bit too excessive IMHO.
It makes the log analysis a bit difficult.
Comment 5•3 years ago
|
||
Comment 6•2 years ago
|
||
(In reply to ISHIKAWA, Chiaki from comment #4)
During mochitest run of FULL DEBUG version of C-C TB, I get 3389 lines of similar warning lines from many tests.
3K+ lines are a bit too excessive IMHO.
It makes the log analysis a bit difficult.
Massive needless console clutter looks like something we should avoid for our own sake.
Magnus, is disabling the error messages for Thunderbird as in 4-liner patch of comment 5 acceptable to you?
If yes, can you assign someone?
Updated•2 years ago
|
Assignee | ||
Comment 7•2 years ago
|
||
I don't think that's a good approach. I was looking at bug 1429491 last week. That is really the root of most of this problem
Great, I am compiling TB now (after rustup update failed for some mysterious reason to update rustc. I had to remove ~/.rustup and retry.)
WIll report back if the quirks mode warnings disappear.
Assignee | ||
Comment 9•2 years ago
•
|
||
There's many cases left that still triggers it. Some are valid warnings, some perhaps not.
I(In reply to Magnus Melin [:mkmelin] from comment #9)
There's many cases left that still triggers it. Some are valid warnings, some perhaps not.
The number has come down from 3k+ to 1800+. Not too bad, but probably we need more investigation and fix here.
Problem is that for the last few years, I have noticed many HTML e-mails do not show correctly even if I whitelist the domain and try to show the content using HTML display mode.
This quirks mode issue may be the reason.
Most of the times, I have noticed that the graphics in the HTML e-mail are not shown correctly. They are shown as broken.
(Come to think of it, they may be filtered by proxy or very spartan DNS I use to cut down the noise from ads sites. But I checked and most of them are often valid Facebook links in e-mails from Facebook, or Amazon links in e-mails from Amazon. Amazon e-mails look better. They may have changed the way graphics links are inserted in the marketing e-mails.)
I am showing the screen capture of a recent HTML e-mail from a ticket sales store.
I have no idea what the broken images are. There is no link associated with it. Maybe the favicons are not defined for the link next to it?
These marketers have realized that their HTML e-mails may not be shown as intended and so usually offers a URL to click to show undisturbed web page.
In the original e-mail of the attached image,
the uppermost link (ZDNET) is
https://enews.zdnet.com/ct/60621629:WRIvQIhNF:m:1:2369779485:557226C6C78FE9745E67CC32905BEBC1:r
The second link (placeholder) is
https://enews.zdnet.com/ct/60621629:WRIvQIhNF:m:1:2369779485:557226C6C78FE9745E67CC32905BEBC1:r
Maybe TB does not handle redirect very well?
Comment 12•2 years ago
|
||
(In reply to ISHIKAWA, Chiaki from comment #11)
In the original e-mail of the attached image,
the uppermost link (ZDNET) is
https://enews.zdnet.com/ct/60621629:WRIvQIhNF:m:1:2369779485:557226C6C78FE9745E67CC32905BEBC1:r
The second link (placeholder) is
https://enews.zdnet.com/ct/60621629:WRIvQIhNF:m:1:2369779485:557226C6C78FE9745E67CC32905BEBC1:r
Please attach the EML files.
(In reply to b1 from comment #12)
(In reply to ISHIKAWA, Chiaki from comment #11)
In the original e-mail of the attached image,
the uppermost link (ZDNET) is
https://enews.zdnet.com/ct/60621629:WRIvQIhNF:m:1:2369779485:557226C6C78FE9745E67CC32905BEBC1:r
The second link (placeholder) is
https://enews.zdnet.com/ct/60621629:WRIvQIhNF:m:1:2369779485:557226C6C78FE9745E67CC32905BEBC1:rPlease attach the EML files.
Here is a sanitized version.
I removed many header lines that revealed the mail servers used, etc.
I also changed the appearances of e-mail addresses in the body of HTML.
It was very revealing that ZDNET e-mail tries to track users by showing presumably one-by-one pixel images. (Not sure if TB HTML e-mail reader tries to protect such tracking in comparison to FF.)
Anyway, I read the HTML portion of the sanitized e-mail using Google Chrome and it rendered just fine.
So my sanitizing it should not cause a problem for analysis of the problem here.
(My local FF is configured to use Privoxy proxy and I have an add blocker, and obviously they made FF fail to show a few links for ads. )
Comment 14•2 years ago
•
|
||
It was very revealing that ZDNET e-mail tries to track users by showing presumably one-by-one pixel images. (Not sure if TB HTML e-mail reader tries to protect such tracking in comparison to FF.)
One of them is 10000x1 gif pixel. How clever. even if FF tries to block 1x1 or some such pixel, I wonder if it blocks 10000x1 gif that is used for tracking. (It may be even used as a seemingly valid horizontal line in combination with CSS. Devilishly clever.)
Actually, I did not modify the strange strings. They may encode the original e-mail addresses, etc.
I tried to include the 10000x1 pixel link in the preceding comment.
Depending on your adblocking proxy, etc. in your FF, you may not see it when you see comment 23.
I do NOT. What a nice suprise. :-)
But that URL will be in the attachment I uploaded anyway.
Assignee | ||
Comment 16•2 years ago
|
||
There are many places this can't be avoided, like about:blank used for composition, even on the web. While in theory it may occasionally be applicable for internal pages, it doesn't seem worth warning about.
Console message: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”." {file: "moz-nullprincipal:{a8ab26eb-ab25-4182-a032-60c3077b4b2c}" line: 0}]
Console message: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”." {file: "about:blank" line: 0}]
Console message: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”." {file: "about:blank?" line: 0}]
Console message: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”." {file: "about:blank?compose" line: 0}]
Console message: [JavaScript Warning: "This page is in Quirks Mode. Page layout may be impacted. For Standards Mode use “<!DOCTYPE html>”." {file: "chrome://messenger/content/messengercompose/MsgComposeCommands.js" line: 10587}]
Updated•2 years ago
|
Updated•2 years ago
|
Comment 17•2 years ago
|
||
Comment 18•2 years ago
|
||
bugherder |
Assignee | ||
Updated•2 years ago
|
Description
•