Intent to Implement and Ship: Make document.documentURI behavior match document.URL and DOM spec
57 views
Skip to first unread message
Daniel Cheng
Mar 27, 2015, 10:15:34 AM3/27/15
to blink-dev
dch...@chromium.org
https://dom.spec.whatwg.org/#concept-document-url
1. Make document.documentURI non-nullable to match document.URL.
2. Use about:blank URL for create*Document()-created documents instead of an empty string.
1. Matches Gecko.
2. Matches the spec.
3. Code cleanup (albeit minor) in Document initialization and cleans up some old FIXMEs.
Firefox: Shipped
Internet Explorer: No public signals
Safari: No public signals
Web developers: No signals
Minimal, since Firefox has worked this way since at least 28 June 2011.
None.
Yes.
https://crbug.com/471239
https://www.chromestatus.com/features/4879378597019648
Yes.
PhistucK
Mar 27, 2015, 10:21:59 AM3/27/15
to Daniel Cheng, blink-dev
Any use counters for the following?
- document.documentURI
- document.documentURI when it is null
- document.documentURI that differs from document.URL
- document.documentURI usage in create*Document created documents
☆PhistucK
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Daniel Cheng
Mar 27, 2015, 10:25:31 AM3/27/15
to PhistucK, blink-dev
On Fri, Mar 27, 2015 at 10:21 PM PhistucK <phis...@gmail.com> wrote:
Any use counters for the following?
No.
- document.documentURI- document.documentURI when it is null- document.documentURI that differs from document.URL- document.documentURI usage in create*Document created documents
These last three counters would all measure the same thing.
Daniel
PhistucK
Mar 27, 2015, 10:27:32 AM3/27/15
to Daniel Cheng, blink-dev
An empty string is not null, so not entirely the same thing.
☆PhistucK
Philip Jägenstedt
Mar 27, 2015, 10:31:21 AM3/27/15
to Daniel Cheng, blink-dev
LGTM, I think this change is trivial enough to not use the intent
process at all, but it doesn't hurt of course.
Since this is a readonly attribute it's impossible to add a meaningful
use counter using existing infrastructure, even if you limit the
counter to when null is returned a high usage would tell you nothing
of how the returned value is used.
Philip
process at all, but it doesn't hurt of course.
Since this is a readonly attribute it's impossible to add a meaningful
use counter using existing infrastructure, even if you limit the
counter to when null is returned a high usage would tell you nothing
of how the returned value is used.
Philip
Chris Harrelson
Mar 31, 2015, 1:08:28 PM3/31/15
to Philip Jägenstedt, Daniel Cheng, blink-dev
LGTM, but please add a use counter for overall usage of document.documentURI.
Philip Rogers
Mar 31, 2015, 1:10:30 PM3/31/15
to Chris Harrelson, blink-dev, Philip Jägenstedt, Daniel Cheng
Discussed offline a bit, LGTM3.
Philip Jägenstedt
Apr 1, 2015, 12:06:04 AM4/1/15
to Chris Harrelson, blink-dev, Daniel Cheng
If the change is made at the same time the use counter is added, what can we learn from measuring access to document.documentURI? I don't think any further changes to the attribute are expected.
Chris Harrelson
Apr 1, 2015, 12:09:13 AM4/1/15
to Philip Jägenstedt, blink-dev, Daniel Cheng
Because in general it's nice to know the usage of web APIs.
Philip Jägenstedt
Apr 1, 2015, 3:50:35 AM4/1/15
to Chris Harrelson, blink-dev, Daniel Cheng
I certainly agree that it would be nice to know, but just in
Document.idl there are 56 attributes in addition to documentURI that
are currently not measured. My hunch is that measuring everything of
potential interest would amount to a measurable increase in binary
size and regressions in microbenchmarks. Of course, if documentURI is
of particular interest, then this slippery slope argument is
irrelevant.
Document.idl there are 56 attributes in addition to documentURI that
are currently not measured. My hunch is that measuring everything of
potential interest would amount to a measurable increase in binary
size and regressions in microbenchmarks. Of course, if documentURI is
of particular interest, then this slippery slope argument is
irrelevant.
Chris Harrelson
Apr 1, 2015, 10:59:39 AM4/1/15
to Philip Jägenstedt, blink-dev, Daniel Cheng
I see. Would you be willing to test this speed/size hypothesis? I didn't consider whether use counters would regress performance significantly..
>>>> > email to blink-dev+unsubscribe@chromium.org.
>>>>
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to blink-dev+unsubscribe@chromium.org.
>>>
>>>
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to blink-dev+unsubscribe@chromium.org.
>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to blink-dev+unsubscribe@chromium.org.
>
>
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Philip Jägenstedt
Apr 2, 2015, 2:38:21 PM4/2/15
to Chris Harrelson, blink-dev, Daniel Cheng
For speed, here are two tests of very simple APIs:
window.offscreenBuffering, which always returns true, but involves a virtual call:
Philip
window.offscreenBuffering, which always returns true, but involves a virtual call:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3481
13343-13976 ms with MeasureAs
8974-9245 ms without MeasureAs
document.clear(), which does nothing and is defined in the header:
13343-13976 ms with MeasureAs
8974-9245 ms without MeasureAs
document.clear(), which does nothing and is defined in the header:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3482
5359-6791 ms with MeasureAs
190-205 ms without MeasureAs
These are just the min/max values from testing ~10 times each. No statistics needed to see the difference.
For size, I compared the size in a Mac release build (with component=shared_library) before and after this addition of 7859 use counters:
https://codereview.chromium.org/1058963002/
libblink_web.dylib grew from 66475428 to 67605028 bytes, i.e. ~1MB or ~143 bytes per entry. (This seems like a lot to me, maybe there's padding, alignment or something inflating the results.)
UseCounters are extremely useful, but it seems we should be careful about adding lots of them and about adding counters to commonly used and performance-sensitive APIs like perhaps Node.firstChild. I certainly have not been shy about adding use counters, but mostly for things where some future change seemed somewhat likely.
5359-6791 ms with MeasureAs
190-205 ms without MeasureAs
These are just the min/max values from testing ~10 times each. No statistics needed to see the difference.
For size, I compared the size in a Mac release build (with component=shared_library) before and after this addition of 7859 use counters:
https://codereview.chromium.org/1058963002/
libblink_web.dylib grew from 66475428 to 67605028 bytes, i.e. ~1MB or ~143 bytes per entry. (This seems like a lot to me, maybe there's padding, alignment or something inflating the results.)
UseCounters are extremely useful, but it seems we should be careful about adding lots of them and about adding counters to commonly used and performance-sensitive APIs like perhaps Node.firstChild. I certainly have not been shy about adding use counters, but mostly for things where some future change seemed somewhat likely.
Philip
Reply all
Reply to author
Forward
0 new messages