- From: Simon Pieters <simonp@opera.com>
- Date: Wed, 08 Jan 2014 10:05:15 +0100
- To: "'public-web-perf@w3.org'" <public-web-perf@w3.org>, "'jonas@sicking.cc'" <jonas@sicking.cc>, "e_lawrence@hotmail.com" <e_lawrence@hotmail.com>, "Jatinder Mann" <jmann@microsoft.com>
On Wed, 08 Jan 2014 01:26:23 +0100, Jatinder Mann <jmann@microsoft.com> wrote: > Thanks for the feedback Simon. I have made updates based to the spec, > https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/Beacon/Overview.html, > and some comments below. Thanks, the changes look OK. >> The mechanics used for obtaining the base URL etc has changed recently >> in HTML (and XHR), possibly you >> want to update the algorithm to use it. See e.g. >> http://xhr.spec.whatwg.org/#dom-xmlhttprequest-open > > What parts of that algorithm do you want me to change? change [[ 2. If the JavaScript global environment is a document environment, run these steps: 1. If document is not fully active, throw an "InvalidStateError" exception and terminate the overall set of steps. 2. Set base to the document base URL of document. 3. Set source origin to the origin of document otherwise. 4. Set referrer source to document. 3. If the JavaScript global environment is a worker environment, run these steps: 1. Set base to the script's base URL. 2. Set source origin to the script's origin. 3. Set referrer source to the script's referrer source. ]] to [[ 2. If the JavaScript global environment is a document environment, run these steps: 1. If settings object's responsible document is not fully active, throw an "InvalidStateError" exception and terminate the overall set of steps. 2. Set base to settings object's API base URL. 3. Set source origin to settings object's origin. 4. Set referrer source to settings object's API referrer source's URL. 3. If the JavaScript global environment is a worker environment, run these steps: 1. Set base to settings object's API base URL. 2. Set source origin to settings object's origin. 3. Set referrer source to settings object's API referrer source. ]] >> "These steps may be run even after the document has unloaded." appears >> a bit toothless since the "fetch" >> algorithm aborts at step 10 if the document is unloaded. Also I think >> that the fetching itself is defined in terms >> of the event loop which doesn't work when the document is unloaded >> since the event loop ignores tasks from >> documents that are not fully active. I'm not sure how to fix this but >> the current text seems like it doesn't work. > > This is a tough one and I'm open to suggestions on how we should improve > the processing model text. We definitely do want to make sure that we > mention that the User Agent may run the task after the document has > unloaded, as that's one of the key benefits of the beacon method. Also see https://www.w3.org/Bugs/Public/show_bug.cgi?id=24137 >> The algorithm has a branch for worker environment but that is dead code >> because the IDL only specifies the method >> on Navigator, not WorkerNavigator. > > I've updated the IDL section to add sendBeacon method to the partial > WorkerNavigation interface. Editorial comment: the existing APIs on navigator are specified using [NoInterfaceObject] + implements, like this: [NoInterfaceObject] interface NavigatorNetworkUtils { boolean sendBeacon(...); }; Navigator implements NavigatorNetworkUtils; WorkerNavigator implements NavigatorNetworkUtils; I think the black-box behavior is identical. -- Simon Pieters Opera Software
Received on Wednesday, 8 January 2014 09:04:29 UTC