Wrong Web IDL type for URLs in HTML Standard

[dontcallmedom-bot]

While crawling HTML Standard, wrong Web IDL type for URLs:

• attributes url and src in interface NotRestoredReasons uses DOMString instead of recommended USVString for URLs

_{Cc @dontcallmedom @tidoust}

_{This issue was detected and reported semi-automatically by Strudy based on data collected in webref.}

[annevk]

@rubberyuzu could you take a look at this?

[domenic]

Since these are getters, and are only ever populated by serializing URLs, it should be a non-observable change to just update the spec to align with best practices.

[domenic]

Actually, this is observable for src per the current spec, considering a case like http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=13395 where the actual src="" attribute has been made to contain an unpaired surrogate.

However, this made me wonder if we wrote the current spec correctly. It currently says

Set notRestoredReasonsForDocument's src to the value of document's node navigable's container's src attribute.

Which means it's getting the literal value of the src content attribute.

But I suspect it would be more useful to get the value reflected by the src IDL attribute, which contains the result of parsing-then-serializing the URL. I also suspect that might be how it's implemented in Chromium, since it's pretty easy to just do iframe_element->src().

@rubberyuzu is out on leave for some time, but perhaps @fergald can take a look at this? The action is:

• Clarify what the intended behavior and/or Chromium implementation is, in terms of "literal src="" content attribute value" vs. "parsed-then-serialized src IDL attribute value".
• Write a test for the above, if there isn't one already.
• Depending on the intended behavior:
  • If it's content attribute value: probably no action, and this is a false positive from the bot?
  • If it's IDL attribute value: update the spec to say that.

[domenic]

Actually, I realized I can check the tests myself. They reveal the Chromium implementation does "parsed-then-serialized src IDL attribute value". Since this makes more sense to me anyway, I'll just send a quick PR to reflect that in the spec.

No action needed from @fergald, sorry for the ping.