584285 - Meta tag list: HTML5-style charset is not displayed / meta tags in body are displayed

Status: NEW

(Firefox :: Page Info Window, defect)

Description

[Kohei Yoshino]

HTML5 allows <meta charset="UTF-8"> instead of the traditional <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> format.

In the meta tag list, this new format is ignored and displayed as a blank line.

You can test this at http://mozilla.jp/

The expected result would be
Name: charset
Content: UTF-8

Comment 1

[Philip Chee]

http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/html/nsIDOMHTMLMetaElement.idl?force=1

Hmm nsIDOMHTMLMetaElement.idl doesn't have a HTML5 charset property. Which would make it easier for PageInfo.

Comment 2

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

What's hard about getAttribute()?

Comment 3

[Kohei Yoshino]

Attachment: patch

Comment 4

[Philip Chee]

Array.forEach(metaNodes, function(node) {
  if (node.hasAttribute("charset")
    gMetaView.addRow("charset", node.getAttribute("charset"));
  else
    gMetaView.addRow([metaNodes[i].name || metaNodes[i].httpEquiv, metaNodes[i].content]);
}

Comment 5

[Kohei Yoshino]

I just found that <meta property="*" content="*" /> tags were also not displayed properly. Such tags are used in the Open Graph protocol:
http://opengraphprotocol.org/

Will update the patch.

Comment 6

[Kohei Yoshino]

And we should also support the itemprop attributes.
http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#meta

Comment 7

[Kohei Yoshino]

Attachment: patch v2

Comment 8

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

(In reply to comment #5)
> I just found that <meta property="*" content="*" /> tags were also not
> displayed properly. Such tags are used in the Open Graph protocol:
> http://opengraphprotocol.org/

I feel pretty strongly that we should not support those proprietary extensions.

(In reply to comment #6)
> And we should also support the itemprop attributes.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#meta

Personally, I'm not sure we should do this until we support microdata (Bug 591467). Don't feel strongly about this one, though.

Comment 9

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

(In reply to comment #5)
> I just found that <meta property="*" content="*" /> tags were also not
> displayed properly. Such tags are used in the Open Graph protocol:
> http://opengraphprotocol.org/

I think it doesn't make sense to display the property attribute an <meta> when RDFa allows it on any element. Furthermore, it doesn't make sense to display it without resolving the CURIE and without the context of the larger RDF graph. However, I think we should keep CURIEs out of Gecko and displaying a larger RDF graph in a user friendly way isn't (AFAIK) a solved UI problem in general.

I think we should keep CURIEs out of Gecko, because RDFa 1.0 CURIEs rely on markup features that parse differently in HTML and XHTML and, therefore, violate the HTML Design Principles. I think we should keep RDFa 1.1 CURIEs out of Gecko, because they have the same author confusion characteristics as XML Namespaces (see http://wiki.whatwg.org/wiki/Namespace_confusion ) and implementing them would either be bad for performance or require added complexity to Gecko's DOM implementation to make the prefix resolution fast.

Doing only what the patch does is a slippery slope towards doing more. People would cite is as precedent for *some* RDFa support and ask for more, which would bring in the above-mentioned CURIE badness and the RDF graph complexity issues.

As for the Open Graph Protocol specifically, I think we shouldn't add support for de facto vendor-specific markup (in this case de facto Facebook-specific, AFAICT) even if the markup has "Open" in its name.

(In reply to comment #6)
> And we should also support the itemprop attributes.
> http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#meta

If we add support for Microdata features, it would make sense to use the APIs from bug 591467 to do so. However, I think it doesn't make sense to single out the participation of the <meta> element in Microdata and show it detached from the larger Microdata data model just like it doesn't make sense to detach RDFa-participating <meta> elements from the larger RDF graph.

I suggest going back to attachment 462743 [details] [diff] [review]. r- from me on attachment 496758 [details] [diff] [review], though I realize I'm not the module owner.

Comment 13

[Kohei Yoshino]

OK, let's just forget the Open Graph Protocol.

I've found another issue: the <meta> elements in the <body> are listed.
e.g. http://schema.org/docs/gs.html#advanced_missing

> var metaNodes = gDocument.getElementsByTagName("meta");

querySelectorAll resolves the issue. Will update my patch soon.

Comment 14

[Kohei Yoshino]

Attachment: patch v3

Comment 15

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

Are we sure we don't want to show charset metas from outside the head? (They can take effect.)

Comment 16

[Kohei Yoshino]

I think this Meta Tag List feature in Firefox has intended to display metadata [1] specified in the <head>. So gDocument.querySelectorAll("head meta") would work.

[1] http://wiki.whatwg.org/wiki/MetaExtensions

Comment 17

[Henri Sivonen (:hsivonen) (temporarily away from Bugzilla)]

Is the patch considered ready for review at this point? I wonder if it's possible to write a unit tests for this with reasonable effort.

Comment 18

[Kohei Yoshino]

Still relevant, but I have no time to write tests. Resetting the assignee.

Comment 20

[Matthew N. [:MattN]]

Comment on attachment 560790 [details] [diff] [review]
patch v3

Review of attachment 560790 [details] [diff] [review]:
-----------------------------------------------------------------

::: pageInfo.js
@@ +465,4 @@
>    document.getElementById("encodingtext").value = encoding;
>  
>    // get the meta tags
> +  var metaNodes = gDocument.querySelectorAll("head meta");

I think this should be done in a separate bug since it's orthogonal to the original issue.

@@ +482,5 @@
>  
> +    Array.forEach(metaNodes, function(node) {
> +      if (node.hasAttribute("charset")) {
> +        // get the HTML5-style short-hand charset
> +        gMetaView.addRow("charset", node.getAttribute("charset"));

This feels a bit weird since it's assigning a name of "charset" which could mislead people into thinking the page has <meta name="charset" content="…"> which is invalid. An alternative to this approach would be to simply omit <meta charset="…"> from the list since the resolved encoding is a few lines above the Meta tree. It also feels a bit weird to omit some <meta> elements but I think slightly less so.

Comment 22

[Alexis Wilke]

I have the same problem: certain meta tags do not have a name or a value and the current display looks broken.

I would just display the correct name (i.e. show the property="..." attribute for OpenGraph, it's just the Page Info window!) and which ever way to display the charset.

The current look is much worse if you ask me (i.e. totally blank line for the charset, missing name for OpenGraph.) You can test with this very page. Right click, do Page Info and you'll notice entries with a bank name. To me (and apparently many others, look at all the duplicates) that looks broken!

Comment 23

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 4 duplicates.
:florian, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 24

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.