[Bug 24338] New: Spec should have Fetch for Blob URLs
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24338 Bug ID: 24338 Summary: Spec should have Fetch for Blob URLs Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: a...@mozilla.com QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org The File API should have a Fetch for Blob URLs that uses fetch.spec.whatwg.org fetch a URL algorithm but applied to Blob URLs, and works alongside the parse a URL step described in Bug 17765. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 24339] New: File API should specify Blob.close() with a state in the model and influence on read methods
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24339 Bug ID: 24339 Summary: File API should specify Blob.close() with a state in the model and influence on read methods Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: File API Assignee: a...@mozilla.com Reporter: a...@mozilla.com QA Contact: public-webapps-bugzi...@w3.org CC: public-webapps@w3.org Currently, Blob.close() is specified to throw an error on read methods, but the Blob model doesn't mention a potentially closed state, and how that might be processed, including on Blob URLs. This bug is to: 1. Include Blob.close in the model for the File API, such as a closed state. 2. Tie Blob.close with read methods based on model. 3. Determine what happens to closed Blobs as Blob URLs. The model favors treating closed state blobs as having no bytes. -- You are receiving this mail because: You are on the CC list for the bug.
I need some guidance.
Hello. Please refer to the following bug report: http://code.google.com/p/chromium/issues/detail?id=336292 In summary, all Webkit-derived browsers (excluding Safari 5.1.7 on Windows) do not do in-process (in-instance?) caching when the header is expired. Firefox, IE11 (but not IE10, I think), and Safari 5.1.7 do. Of course, I can easily set the cache to expire after some amount of time to overcome this bug, but this is not good for web development or active websites or web-apps. (you can't see the changes made right away) I can also set every image to a canvas image after loading it as an img, but that is not a really good solution either. Despite that it is, I think, a big problem in terms of website development, the Chrome project (and webkit project) developer community will only likely budge if the specification says that the current behavior is wrong. It's certainly inconsistent with IE and Firefox, but that's not enough. I cannot find any relevant W3C spec on what should be definitively done with in-process or in-instance image caching; maybe W3C image specification handles that, but I could not be positive and so my complaints fell on deaf ears in an earlier bug report. Can you clarify if the current spec speaks to the required behavior? Or, perhaps, if it doesn't, perhaps it should. Thank you, Michael Romanovsky
Re: I need some guidance.
* a...@flyingsoft.phatcode.net wrote: Please refer to the following bug report: http://code.google.com/p/chromium/issues/detail?id=336292 In summary, all Webkit-derived browsers (excluding Safari 5.1.7 on Windows) do not do in-process (in-instance?) caching when the header is expired. Firefox, IE11 (but not IE10, I think), and Safari 5.1.7 do. I take it this is about ordinary HTTP caching behavior, not about, say, appcache, correct? Also, it seems the issue is that you tell browsers not to cache a resource, and then expect it to be cached anyway. Could you elaborate on that? In any case, a better forum for the problem might be a group specialising in HTTP caching questions, e.g. if you want to know what the HTTP specification has to say on this situation. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
[clipboard events] Spec update
I've just comitted a spec update with some significant changes. Please review
and discuss..
Change #1: click-to-copy and click-to-cut
Yesterdays edits introduced a concept called semi-trusted events - in order
to make script-initiated copy and cut operations just work if the script that
initiates them is run in response to user input. See
http://dev.w3.org/2006/webapi/clipops/clipops.html#semi-trusted-event
Discussion that caused this change happened on the list and in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23235
Change #2: more details (and tests for) the beforecopy, beforecut and
beforepaste events.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21696
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21697
Implementations that follow the spec will end up with a better implementation
of before* events that what Internet Explorer has, thus exceeding the (low)
expectations of web developers ;-)
Related note: the spec (and tests) already expects that the firing of
copy/cut/paste events occurs irrespectable of any cursor/selection/editable
context. So if a page with no cursor or selected text is open, and the user
presses ctrl-c, a copy event is expected to fire. If user presses ctrl-x, a cut
is expected to fire. The before* events are all about the state of UI controls,
and have no impact or whether or not actual events fire. (AFAIK both Firefox
and other teams have some work to do to make that happen as expected. We don't
have the thought reading capability to fire beforecopy if the user thinks about
pressing ctrl-c, so there's no way around that.)
Change #3 - no prior discussion, might be a bit controversial?
Synthetic (script-generated) paste events are now defined as causing paste
actions. document.execCommand('copy'|'cut'|'paste') is now from the spec's
point of view just a shortcut for generating and firing synthetic events.
There are two possible ways this works:
1) When creating synthetic clipboard events, the script can specify a data
payload. For example, the default outcome of this script:
var evt = new ClipboardEvent({data:'EHLO WORDL', dataType:'text/plain'})
document.getElementsByTagName('textarea')[0].dispatchEvent(evt)
would be to insert the text 'EHLO WORDL', as if pasted from the clipboard, into
the textarea.
2) UAs may be configured to allow scripted paste operations. In this case,
dispatching a paste event targeted at some element where data can be inserted
(input/textarea/contenteditable etc.) will by default insert the clipboard
data. However, if a data payload was specified for the event (as in the example
above), that data will be used instead of clipboard data.
Is this a good change or a bad idea? Please discuss :-)
Known issue: the Editor's draft is not currently properly cross-linked with
other specs, because I don't have a computer with Anolis set up handy right
now. I'll fix this later. For the same reason, the ED doesn't have a proper
inline table of contents.
-Hallvord
Re: [clipboard events] Spec update
I'm eager to replace our flash clipboard bridge with this native api.
Would this be the correct code to write a string to the clipboard on a
button click?
document.getElementById(copytoclipboard).addEventListener(click,
function() {
var event = new ClipboardEvent('paste', {data: 'COPIED!',
dataType: 'text/plain'});
document.dispatchEvent(event);
});
On Mon, Jan 20, 2014 at 7:55 PM, Hallvord R. M. Steen
hst...@mozilla.com wrote:
I've just comitted a spec update with some significant changes. Please review
and discuss..
Change #1: click-to-copy and click-to-cut
Yesterdays edits introduced a concept called semi-trusted events - in order
to make script-initiated copy and cut operations just work if the script
that initiates them is run in response to user input. See
http://dev.w3.org/2006/webapi/clipops/clipops.html#semi-trusted-event
Discussion that caused this change happened on the list and in
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23235
Change #2: more details (and tests for) the beforecopy, beforecut and
beforepaste events.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21696
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21697
Implementations that follow the spec will end up with a better implementation
of before* events that what Internet Explorer has, thus exceeding the (low)
expectations of web developers ;-)
Related note: the spec (and tests) already expects that the firing of
copy/cut/paste events occurs irrespectable of any cursor/selection/editable
context. So if a page with no cursor or selected text is open, and the user
presses ctrl-c, a copy event is expected to fire. If user presses ctrl-x, a
cut is expected to fire. The before* events are all about the state of UI
controls, and have no impact or whether or not actual events fire. (AFAIK
both Firefox and other teams have some work to do to make that happen as
expected. We don't have the thought reading capability to fire beforecopy if
the user thinks about pressing ctrl-c, so there's no way around that.)
Change #3 - no prior discussion, might be a bit controversial?
Synthetic (script-generated) paste events are now defined as causing paste
actions. document.execCommand('copy'|'cut'|'paste') is now from the spec's
point of view just a shortcut for generating and firing synthetic events.
There are two possible ways this works:
1) When creating synthetic clipboard events, the script can specify a data
payload. For example, the default outcome of this script:
var evt = new ClipboardEvent({data:'EHLO WORDL', dataType:'text/plain'})
document.getElementsByTagName('textarea')[0].dispatchEvent(evt)
would be to insert the text 'EHLO WORDL', as if pasted from the clipboard,
into the textarea.
2) UAs may be configured to allow scripted paste operations. In this case,
dispatching a paste event targeted at some element where data can be inserted
(input/textarea/contenteditable etc.) will by default insert the clipboard
data. However, if a data payload was specified for the event (as in the
example above), that data will be used instead of clipboard data.
Is this a good change or a bad idea? Please discuss :-)
Known issue: the Editor's draft is not currently properly cross-linked with
other specs, because I don't have a computer with Anolis set up handy right
now. I'll fix this later. For the same reason, the ED doesn't have a proper
inline table of contents.
-Hallvord
Re: [clipboard events] Spec update
I'm eager to replace our flash clipboard bridge with this native api.
Uh, I'm glad you like it but I wouldn't hold my breath.. I hope implementors
will like it too but I have no way to tell when implementations will actually
be available.
Would this be the correct code to write a string to the clipboard on a
button click?
Almost, just create a copy event rather than a paste one ;-)
document.getElementById(copytoclipboard).addEventListener(click,
function() {
var event = new ClipboardEvent('paste', {data: 'COPIED!',
This is where 'paste' ought to be 'copy'. Then it should just work.
dataType: 'text/plain'});
document.dispatchEvent(event);
});
-Hallvord
