This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This was was cloned from bug 15095 as part of operation convergence. Originally filed: 2011-12-07 06:28:00 +0000 ================================================================================ #0 contributor@whatwg.org 2011-12-07 06:28:30 +0000 -------------------------------------------------------------------------------- Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html Multipage: http://www.whatwg.org/C#dom-worker Complete: http://www.whatwg.org/c#dom-worker Comment: Allow data: URL for new Worker(). Supported by Opera and Firefox. Posted from: 85.227.157.105 by simonp@opera.com User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8) AppleWebKit/535.8 (KHTML, like Gecko) Chrome/17.0.942.0 Safari/535.8 ================================================================================ #1 Ian 'Hixie' Hickson 2011-12-07 23:29:19 +0000 -------------------------------------------------------------------------------- So to do this I guess we just hack the origin to be the origin of the caller if the worker URL is a data: URL? ================================================================================ #2 Simon Pieters 2011-12-08 09:16:08 +0000 -------------------------------------------------------------------------------- http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1274 - currently Firefox returns the empty string, Opera returns the full data: URL (although I think we have changed that to return 'null' instead). Since workers can use XHR, EventSource and WebSocket, I think it would be better to use the origin of the entry script. Opera currently doesn't allow data: for shared workers (and Firefox doesn't support shared workers at all), but we have discussed adding support for it, but here it's more important than with dedicated workers that the origin is that of the caller, so that different origin pages that use the same data: URL for a shared worker don't actually share the worker, but use separate ones. ================================================================================
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the Editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the Tracker Issue; or you may create a Tracker Issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: https://github.com/w3c/html/commit/fefc216ad6fd06e8e48557de56b3cf957fd95cf9 Rationale: accepted WHATWG fix
Silvia - I don't see a new checkin in the Workers spec's CVS repository <http://dev.w3.org/cvsweb/html5/workers/Overview.html>. Was this bug fixed in some previous revision?
Oops, I'm sorry I got this mixed up as a bug of the HTML spec. Instead, it's part of the WebAppsWG. It has been applied by Ian in https://www.w3.org/Bugs/Public/show_bug.cgi?id=15095 , so you might want to check if that text has been pulled into the W3C spec. Sorry for the confusion.
I checked the CVS log and this bug was fixed in r1.339 (9-Aug-2012) <http://dev.w3.org/cvsweb/html5/workers/Overview.html.diff?r1=1.338;r2=1.339;f=h> (aka r/7236) so I'm changing it back to fixed.
Silvia, can you please take more care about resolving WebApps bugs? Maybe a user style for body.bz_product_WebAppsWG could help...
I certainly will. I now know what to pay attention to. I apologize this was part of my first larger attempt at dealing with HTML WG bugs. Sorry about the 3 WebApps Bugs I should not have touched. :-(