Last Comment Bug 802548 - HTML5 microdata gives special meaning to itemId breaking some web content
: HTML5 microdata gives special meaning to itemId breaking some web content
Status: NEW
: regression, site-compat, testcase
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: x86_64 Windows 7
: -- major (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 802831 (view as bug list)
Depends on: 909633
Blocks: 591467
  Show dependency treegraph
 
Reported: 2012-10-17 04:15 PDT by clemensdev
Modified: 2016-05-12 08:53 PDT (History)
14 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
example html showing the misbehavior (315 bytes, text/html)
2012-10-17 04:15 PDT, clemensdev
no flags Details

Description clemensdev 2012-10-17 04:15:37 PDT
Created attachment 672247 [details]
example html showing the misbehavior

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20121010150351

Steps to reproduce:

As of Firefox 16, when setting itemId-attribute on a <li>-element, and then reading it the URI of the current page is prepended to the given value


Actual results:

given the following html:
<html><body><ul><li id="li1"></li></ul><script>
var element = document.getElementById("li1");
// assign to bla
element.bla = "hello";
// after
alert( element.bla ); // ok -> hello
// assign
element.itemId = "hello";
// after
alert( element.itemId ); // nok -> <file uri>hello
</script>
</body>
</html>



Expected results:

we should be getting two alerts with "hello"! All other browsers and FF < 16 behave alike ...
Comment 1 clemensdev 2012-10-17 04:19:38 PDT
also:
"alert( typeof( element.itemId ) );" is "string" (instead of "undefined") even before setting the value. This indicates that itemId is kind of "in use" ...
Comment 2 Patricia 2012-10-17 06:07:06 PDT
This doesn't only affect <li> it also affects checkboxes, and i imagine other form elements.
  
See this JS Fiddle:

http://jsfiddle.net/K8jRf/1/

when attempting to access my attribute itemId it puts the url in front. needless to say this broken some of my code pretty badly.
Comment 3 Patricia 2012-10-17 06:15:52 PDT
I've updated my jsFiddle. that one in my comment was not the right version:
http://jsfiddle.net/K8jRf/8/
Comment 5 Boris Zbarsky [:bz] 2012-10-17 10:47:44 PDT
"itemId" is part of the HTML5 microdata API, which shipped in Firefox 16.  See http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#dom-itemid

In particular, the spec there says:

   The itemId IDL attribute on HTML elements must reflect the itemid content attribute.

and http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#attr-itemid says:

   The itemid attribute, if specified, must have a value that is a valid URL potentially
   surrounded by spaces.

and http://www.whatwg.org/specs/web-apps/current-work/multipage/common-dom-interfaces.html#reflect says:

   If a reflecting IDL attribute is a DOMString attribute whose content attribute is
   defined to contain a URL, then on getting, the IDL attribute must resolve the value
   of the content attribute relative to the element and return the resulting absolute URL
   if that was successful, or the empty string otherwise; and on setting, must set the
   content attribute to the specified literal value.

So looking at the testcase from comment 0:

   element.itemId = "hello";  // equivalent to element.setAttribute("itemid", "hello");
   alert( element.itemId ); // Should return what happens when the relative URI "hello"
                            // is resolved relative to the document base URI

Jonas, Mounir, Olli, at what point do we decide that microdata is breaking too many web pages and push back on the spec?  ;)
Comment 6 Jonas Sicking (:sicking) PTO Until July 5th 2012-10-17 11:21:41 PDT
It sounds like this page is trying to use the microdata API, so backing it out wouldn't fix anything.

I don't know the microdata API well enough to have an opinion on if it should be changed to cause fewer conflicts with existing pages, or be easier to use, or otherwise improved. I thibk Henri knows the spec better and might have suggestions.
Comment 7 Boris Zbarsky [:bz] 2012-10-17 11:26:26 PDT
> It sounds like this page is trying to use the microdata API

No, it's not.  There is not an itemprop in sight.  It's just trying to use "itemId" attrs to keep track of info of its own choosing.  Basically, it should be using "data-itemid" so it'll be guaranteed to not collide with future properties, but it's not.

ccing Henri for his comments...
Comment 8 Patricia 2012-10-17 12:23:00 PDT
boris is correct.  i am just using itemId as a holder for some info.  This page was built before the popularity of html 5's data-whatever.  

if i reference it by itemid instead of itemId (even though my casing in the html is, infact, itemId)  it works fine.
Comment 9 Boris Zbarsky [:bz] 2012-10-17 12:34:43 PDT
Attribute names are case-insensitive, so as long as you end up in getAttribute it won't matter whether you use "itemid" or "itemId".  That said, comment 0 has nothing in the HTML.

The fiddle dose have stuff in the HTML, and is using jQuery attr(), which is broken in old jQuery versions (which is what jsfiddle uses) and tries DOM properties in preference to getAttribute.  So in cases where your real problem is jQuery attr(), just updating to a recent jQuery should help.
Comment 10 Loic 2012-10-18 05:44:10 PDT
*** Bug 802831 has been marked as a duplicate of this bug. ***
Comment 11 Nickolay_Ponomarev 2012-11-18 10:18:06 PST
Getting this off the Firefox:Untriaged list.
Comment 12 Paul Pasca[Away. Please needinfo? Paul Oiegas [:pauloiegasSV]] 2016-05-12 02:29:37 PDT
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160502172042

I have tested your issue on latest FF release (46.0.1), latest Nightly build (20160511030221) and managed to reproduce it. I have opened the provided link in comment 0 and Firefox fires only one alert with "hello". IE and Chrome work as expected.
Comment 13 Kohei Yoshino [:kohei] 2016-05-12 08:53:27 PDT
FYI: This has been documented at https://www.fxsitecompat.com/en-CA/docs/2012/microdata-api-has-added-new-properties-to-elements/

Note You need to log in before you can comment on or make changes to this bug.