Closed
Bug 615617
Opened 14 years ago
Closed 14 years ago
GetDocumentMetadata does not return data from META elements added by scripts (breaks jQuery Mobile)
Categories
(Core :: DOM: Core & HTML, defect)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
fennec | 2.0+ | --- |
People
(Reporter: mbrubeck, Assigned: blassey)
References
()
Details
(Keywords: compat, mobile)
Attachments
(1 file)
1009 bytes,
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
nsDOMWindowUtils::GetDocumentMetadata (which uses nsIDocument::GetHeaderData) does not return any values from <meta> nodes inserted with JavaScript. For example, http://jquerymobile.com/demos/1.0a2/ inserts a <meta name="viewport"> element into the <head>. Fennec receives a DOMMetaAdded event when the element is inserted, but GetDocumentMetadata does not return the added values.
Reporter | ||
Updated•14 years ago
|
Updated•14 years ago
|
tracking-fennec: ? → 2.0+
Comment 1•14 years ago
|
||
For some <meta> elements GetDocumentMetadata _should_ ignore dynamically-added ones. For example, http-equiv="content-type". What's the list of metas that need to be handled dynamically here?
Reporter | ||
Comment 2•14 years ago
|
||
(In reply to comment #1) > For some <meta> elements GetDocumentMetadata _should_ ignore dynamically-added > ones. For example, http-equiv="content-type". > > What's the list of metas that need to be handled dynamically here? Just <meta name="viewport"> would be fine.
Comment 3•14 years ago
|
||
OK. So I assume GetDocumentMetadata should reflect the first <meta name="viewport"> in the DOM? Should it restrict to <head>, or just anywhere in the DOM?
Reporter | ||
Comment 4•14 years ago
|
||
That might be fine. The only cases I've found in the wild are pages that have no <meta name="viewport"> in the HTML, and then add one to <head> on "load". There's no standard or spec for this, so I'll do some testing later today to see what WebKit and other browsers do for comparison.
Reporter | ||
Comment 5•14 years ago
|
||
The WebKit browsers in Android 2.2 and iOS 4 (tested on iPad) use the contents of the last <meta name="viewport">, rather than the first. However, meta elements inserted dynamically always override any existing viewport settings, even if the dynamic element is inserted higher in the DOM than the existing one. Meta elements in the body are treated the same as in the head, and elements can be inserted using appendChild (both during and after the "load" event), or written using document.write. Test cases at http://limpet.net/test/vp0.html through http://limpet.net/test/vp9.html
Reporter | ||
Comment 6•14 years ago
|
||
Opera Mobile for Android behaves the same as WebKit for all the test cases in comment 5.
Comment 7•14 years ago
|
||
Ugh, hysteresis. That's really annoying. :( I guess you could just hack nsHTMLMetaElement::BindToTree to update the document metadata to get this behavior, right? The "use the last" behavior is just a consequence of "whenever something is inserted it overrides the value", since the parser mostly inserts in tree order.
Assignee | ||
Comment 8•14 years ago
|
||
(In reply to comment #1) > What's the list of metas that need to be handled dynamically here? Would it be better to have a black list of metas that shouldn't be handled dynamically?
Comment 9•14 years ago
|
||
Hard to say. Dynamic handling costs. Depending on how it's implemented, it could cost on any DOM mutation, and the longer the list the more cost. Matt, what happens when you _remove_ a <meta name="viewport"> from the DOM in webkit? I bet it doesn't change the viewport at that point....
Assignee | ||
Comment 10•14 years ago
|
||
Assignee: nobody → blassey.bugs
Assignee | ||
Updated•14 years ago
|
Attachment #495790 -
Flags: review?(bzbarsky)
Comment 11•14 years ago
|
||
You can take the hunk in nsContentSink that also does this out now, right? Also s/nsnull/kNamespaceID_None/
Comment 12•14 years ago
|
||
Comment on attachment 495790 [details] [diff] [review] patch r=me with those two changes, though duplicating the webkit bugginess here makes me really sad. Can we talk to them about fixing that?
Attachment #495790 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 13•14 years ago
|
||
pushed http://hg.mozilla.org/mozilla-central/rev/ded653253911
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 14•14 years ago
|
||
(In reply to comment #12) > Can we talk to them about fixing that? filed bug 617331
Reporter | ||
Comment 15•14 years ago
|
||
(In reply to comment #9) > Matt, what happens when you _remove_ a <meta name="viewport"> from the DOM in > webkit? I bet it doesn't change the viewport at that point.... That's correct. Removing the <meta> element does not change the viewport in WebKit. Test case at http://limpet.net/test/vp10.html
You need to log in
before you can comment on or make changes to this bug.
Description
•