Re: [clipboard] Add RTF to the "mandatory data types" list?

On Mon, Apr 20, 2015 at 11:01 PM James M. Greene wrote: >> That behavior is really all I wanted, i.e. "don't let the browser >> discard/ignore valid RTF clipboard data". On Wed, May 6, 2015 at 8:18 PM, Daniel Cheng wrote: > I don't think I would

[clipboard][DnD][DataTransfer] custom types and security

Hi public-webapps, or the sub-set of your that are interested in clipboard and DnD stuff: we've started an interesting thread regarding DataTransfer, custom types and security here https://github.com/whatwg/html/issues/1244 and implementor input is especially welcome. Allow me to paste parts of

Re: Clipboard API: Proposal for asynchronous API

Hi Gary, good work! Some questions that have come up in discussion with developers at Mozilla: 1) The existing DataTransfer API is purposefully designed to be used for both copy/paste and drag-and-drop. If we add navigator.clipboard to add asyncness to clipboard-style usage of the API, what about

Re: Clipboard API: remove dangerous formats from mandatory data types

Relevant to this thread - I've just reported an issue on making the DataTransfer API safer: https://github.com/whatwg/html/issues/1244 Input there would be great. I'm planning to look at how to add this to the spec, but I'm not sure what exactly it should say. I would still like comments from

Re: [XHR]

On Tue, Mar 15, 2016 at 11:19 PM, Gomer Thomas wrote: > According to IETF RFC 7230 all HTTP recipients “MUST be able to parse the > chunked transfer coding”. The logical interpretation of this is that > whenever possible HTTP recipients should deliver the chunks to

Re: [clipboard] kill onbefore* events?

On Thu, Mar 10, 2016 at 4:23 AM, Johannes Wilm wrote: > Once I get back to work, I will start to program a version 5.0 of my editor > that handles the new eventtype correctly. > > Anyone still not having upgraded from version 4.35, the editor doesn't end > up doing

Re: [clipboard] kill onbefore* events?

> Just using mutation observers, one can see the change that was made, but > doesn't really know what the user's intentions were, right? I guess so, haven't used them for anything. Perhaps the "after the fact" nature was a design flaw in Mutation Observers. > The browser meeting also came up

Re: [clipboard] kill onbefore* events?

On Mon, Mar 7, 2016 at 11:00 PM, Gary Kacmarcik (Кошмарчик) wrote: > Agreed. That is the major benefit of 'beforeinput' and 'input' -- you will > receive a 'beforeinput' event just before any DOM update (with an option to > cancel it), and you'll also receive an 'input'

Re: [clipboard] kill onbefore* events?

Hi Johannes, thanks for commenting here. It was recently brought to my attention in a GitHub issue that using the term "before* events" was misleading as it sounds like I also mean beforeInput when the clipboard spec is only about beforecopy, beforecut and beforepaste. I think you may also have

[clipboard] Sanitizing HTML content for security/privacy on copy or paste?

Hi, some discussion of how browsers can try to safeguard security/privacy while copying/pasting HTML got tangled into the "remove dangerous formats from mandatory data types" thread [1]. I think it will be easier to follow with a separate thread. Context: we're talking copy from any normal public

Re: Clipboard API: remove dangerous formats from mandatory data types

> But copying a fragment of HTML in the wild without reformulating it will > lead to privacy breach: it would copy references to external content. I > believe all browsers have an "inlining" method to solve that problem I'm trying to handle this question on another E-mail thread so please follow

Re: Clipboard API: remove dangerous formats from mandatory data types

On Mon, Feb 8, 2016 at 7:45 PM, Wez wrote: > Hallvord, > > IIUC the issue is that while transcoding complex formats via formats that > can be easily sanity-checked by the browser takes care of letting content > set complex formats like JPEG, GIF while protecting local content,

Re: Clipboard API: remove dangerous formats from mandatory data types

BTW, we have a slightly related and interesting discussion regarding custom data types going on here: https://bugzilla.mozilla.org/show_bug.cgi?id=860857 I should try to sum up some of the arguments and proposals and present them on this list but if anyone wants to chime in, I'd appreciate more

Re: [clipboard] kill onbefore* events?

On Thu, Feb 4, 2016 at 2:43 AM, Grisha Lyukshin wrote: > > Killing them doesn't sound like the right course of action. We would have to > come up > with another API so we can have an alternative to what before cut/copy/paste > do. True, it's a use case we should handle.

Re: Clipboard API: remove dangerous formats from mandatory data types

(Finally found some time to resume this old discussion - if you've all forgotten the details by now the thread started here: https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0819.html ) On Sat, Aug 29, 2015 at 3:16 PM, Paul Libbrecht wrote: > But copying a

Re: [clipboard] kill onbefore* events?

ng context "I'm about to do a cut/paste/copy") > > On Tue, Feb 2, 2016 at 2:00 PM, Hallvord Reiar Michaelsen Steen < > hst...@mozilla.com> wrote: > >> Hi, >> there's some scepticism about implementing >> onbeforecut/onbeforepaste/onbeforecopy in Gecko

[clipboard] kill onbefore* events?

Hi, there's some scepticism about implementing onbeforecut/onbeforepaste/onbeforecopy in Gecko [1], IE's implementation seems considerably more limited than I expected (maybe because of bugs?), and it doesn't really seem like an elegant solution to the use case it is meant to solve. Would anybody

Re: [clipboard] document.execCommand and clipboard actions

On Thu, Aug 6, 2015 at 11:00 AM, yves.ko...@ysadi.be wrote: Hi, Sorry if I might be out of scope, I am quite new in this mailing list. Welcome, and sorry that I'm late at responding. The clipboard is aimed to exchange any? data between any apps running on your computer. It is not a

Re: Clipboard API: remove dangerous formats from mandatory data types

On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng dch...@google.com wrote: Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg

Re: [clipboard] document.execCommand and clipboard actions

On Thu, Aug 6, 2015 at 9:09 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Aug 4, 2015 at 11:31 PM, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: so I hit a bit of an issue: I've written some parts of the clipboard spec with the assumption that it will be invoked from

Re: W3C's version of XMLHttpRequest should be abandoned

On Thu, Aug 6, 2015 at 9:15 AM, Anne van Kesteren ann...@annevk.nl wrote: According to Art https://dvcs.w3.org/hg/xhr/raw-file/default/Overview.html is no longer maintained. It should redirect to https://xhr.spec.whatwg.org/ therefore. Well, I don't think he said exactly it's not maintained

Re: [clipboard] document.execCommand and clipboard actions

On Wed, Aug 5, 2015 at 2:34 AM, MOHAN ARUN mar...@gmail.com wrote: Would implementors want to support (writing stuff to the clipboard)? Yes, we really, really want to allow that - at least for simple cases. There are plenty of complex questions - for example what formats is it safe to let JS

[clipboard] document.execCommand and clipboard actions

Hi, so I hit a bit of an issue: I've written some parts of the clipboard spec with the assumption that it will be invoked from a document.execCommand('copy'/'cut'/'paste') call (although 'paste' would require some extra permission work which no UA but IE has attempted so far). Meanwhile, the

Re: Clipboard API: remove dangerous formats from mandatory data types

On Tue, Jul 28, 2015 at 1:08 PM, Chaals McCathie Nevile cha...@yandex-team.ru wrote: I'm just thinking out loud here, but this problem is similar to one already faced by email clients, especially those which are web-based... On Mon, 27 Jul 2015 15:03:40 -0400, Hallvord Reiar Michaelsen Steen

Re: Clipboard API: remove dangerous formats from mandatory data types

On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng dch...@google.com wrote: Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg

[clipboard] navigator.registerClipboardFormats( ... )

Hi, there's an interesting proposal here https://github.com/w3c/clipboard-apis/issues/9 for solving our what about clipboard data from various native applications? conundrum. The proposal is to let a page indicate what native clipboard identifiers it is interested in handling:

Re: Clipboard API: remove dangerous formats from mandatory data types

On Thu, Jun 11, 2015 at 8:57 PM, Elliott Sprehn espr...@chromium.org wrote: I don't think the clipboard should forbid inserting image data, there's so many ways to compromise desktop software. ex. pasting text/html into Mail.app might even do it. This API shouldn't be trying to prevent that.

Re: Clipboard API: remove dangerous formats from mandatory data types

On Thu, Jun 11, 2015 at 7:51 PM, Wez w...@google.com wrote: Hallvord, The proposal isn't to remove support for copying/pasting images, but to restrict web content from placing compressed image data in one of these formats on the clipboard directly - there's no issue with content pasting raw

Re: Clipboard API: remove dangerous formats from mandatory data types

On Tue, Jun 9, 2015 at 8:39 PM, Daniel Cheng dch...@google.com wrote: Currently, the Clipboard API [1] mandates support for a number of formats. Unfortunately, we do not believe it is possible to safely support writing a number of formats to the clipboard: - image/png - image/jpg, image/jpeg

Re: Clipboard API: remove dangerous formats from mandatory data types

On Wed, Jun 10, 2015 at 1:23 AM, Ashley Gullen ash...@scirra.com wrote: The browser could copy a terminal command to wipe the disk, and the user could run it. Or copy a URL to a web page that has a known security exploit, and then the user pastes it in to the address bar. Maybe we shouldn't

[clipboard] queryCommandEnabled() and before* events

Hi, I've just reported https://github.com/w3c/clipboard-apis/issues/4 - pasting text below: Through onbefore* events, JS can ensure copy/cut/paste UI in the browsers is enabled even if there is no selection or editable context. However, unless we spec queryCommandEnabled() to fire onbefore*

Re: [clipboard] Feature detect Clipboard API support?

On Sun, Apr 26, 2015 at 4:32 PM, James M. Greene james.m.gre...@gmail.com wrote: They used `Document#queryCommandSupported` and `Document#queryCommandEnabled` for feature detection -- the latter requiring that there is an active, expanded Selection/Range in the Document in order to get a

[clipboard] Dilemma: getData('text/html') and useful CF_HTML quirks

We're exploring text/html paste behaviours in Mozilla bug 586587 [1] and running into some tricky questions I'd like to discuss here. Basically, on Windows IE and other apps that write HTML to the clipboard use the CF_HTML format. This format is simply described as headers (name:value meta

Re: [clipboard] Feature detect Clipboard API support?

(Aside: I was testing the queryCommandEnabled()/onbefore* idea with this script: https://gist.github.com/hallvors/59a90f2e3816cb57f044 ) On Tue, Apr 21, 2015 at 7:29 AM, James M. Greene james.m.gre...@gmail.com wrote: Patrick Kettner offered up another idea for this as well on a related

Re: [clipboard events] click-to-copy support could be hasFeature discoverable?

On Fri, May 23, 2014 at 5:13 PM, Glenn Maynard gl...@zewt.org wrote: Hallvord: By the way, please add the editor of the HTML spec to the beginning of the list in your references. It's strange to list a bunch of author names, but not the person who actually writes the spec. Is anything

Re: [clipboard] Feature detect Clipboard API support?

On Wed, Feb 11, 2015 at 7:21 PM, James M. Greene james.m.gre...@gmail.com wrote: The current spec still leaves me a bit unclear about if implementors must include the ability to feature detect Clipboard API support, which I think is a critical requirement. I agree it's a very important

Re: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data

In addition, from a security perspective, what stops a malicious website from embedding something like img src=file:///etc/passwd style=display:none/img in the markup? We disallow this on copy by stripping such references. Hi Ben, picking up this old thread.. So we need to add a sanitize

Re: XMLHttpRequest and timing of upload events

Hi Anne, sorry to be late at responding - just going through some E-mail I didn't have time to understand and respond to before.. On Tue, May 20, 2014 at 2:55 PM, Anne van Kesteren ann...@annevk.nl wrote: Because redirects are atomic, we cannot dispatch loadend events and such on the

Re: [clipboard events] seeking implementor feedback on using CID: URI scheme for pasting embedded binary data

So, the E-mail to Ben Peters bounced - he's no longer at Microsoft? Is there anyone on the IE team present on the list who is able to comment on this? -Hallvord R On Mon, Apr 20, 2015 at 10:38 PM, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: In addition, from a security

Re: [clipboard] Add RTF to the mandatory data types list?

I assume that mandating all engines have built-in RTF parsers/converters to translate back and forth between RTF and HTML is going too far.. Apparently IE did / does just that, but even so it seems like RTF is generally fading away. Would it be a possible compromise to let a script describe data

Re: [clipops][editing] document.execCommand('copy', false, 'some data') ?

On Sat, Apr 11, 2015 at 8:16 PM, Aryeh Gregor a...@aryeh.name wrote: element.onclick = function(){ document.execCommand('copy', false, 'foo'); } Is this really copying? As in an operation that places some data on the system clipboard, yes ;) but I see your point of view. I think

Re: [XHR] UTF-16 - do content sniffing or not?

Which MIME type did you use in the response? BOM sniffing in XML is non-normative IIRC. For other types, see below. It's text/plain - seems I definitely need one test with an XML response too.. and one with JSON. [[ If charset is null, set charset to utf-8. Return the result of running

Re: [XHR] UTF-16 - do content sniffing or not?

On Mon, Mar 23, 2015 at 1:45 PM, Simon Pieters sim...@opera.com wrote: On Sun, 22 Mar 2015 23:13:20 +0100, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: Given a server which sends UTF-16 data with a UTF-16 BOM but does *not* send charset=UTF-16 in the Content-Type header

[XHR] UTF-16 - do content sniffing or not?

Hi, I've just added a test loading UTF-16 data with XHR, and it exposes an implementation difference that should probably be discussed: Given a server which sends UTF-16 data with a UTF-16 BOM but does *not* send charset=UTF-16 in the Content-Type header - should the browser detect the encoding,

Re: [clipboard API] platform integration stuff - in spec or out of scope?

On Wed, Feb 11, 2015 at 3:34 PM, James M. Greene james.m.gre...@gmail.com wrote: We never really came to a decision on if RTF (application/rtf) should be listed as a mandatory MIME type but the general consensus seemed to be leaning toward yes:

Re: [clipboard API] platform integration stuff - in spec or out of scope?

I don't know what these map to on platforms that do not use MIME types to describe clipboard contents. Should this information be dug up and included? First request: can we add the three MathML media-types? I know you've brought this up before, I haven't done anything about it and it's partly

Re: Clipboard API: Default content in copy/cut handlers

On Fri, Jul 12, 2013 at 1:22 AM, Daniel Cheng dch...@google.com wrote: I've noticed that the way that drag-and-drop processing model is written, the default content that would be in the drag data store is available in the dragstart event.

Re: [XHR] anonymous flag

Den 1. juni 2013 kl. 10:14 skrev Anne van Kesteren ann...@annevk.nl: On Thu, May 30, 2013 at 1:30 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: So creating a new tri-state property in the XHR spec should also simplify integration with the Fetch spec. Agreed. The question

Re: Re: [XHR] anonymous flag

Now, if you are still not convinced this is a good change my plan B is to suggest a credentialsPolicy property so we'll find an agreement anyway. :-) But maybe explaining that no quirky getter magic is required helps you see the proposal in a new light? Whatever we're doing here is

Re: Re: Re: [XHR] anonymous flag

OK then - Anne and others, what do you think about creating a new tri-state xhr.credentialsPolicy property and discouraging usage of xhr.withCredentials ? I think I'd prefer removing the constructor flag and leaving new features to the API for Fetch. Sorry, I don't understand what

Re: [XHR] anonymous flag

I proposed that we modify withCredentials to take three values: samedomain (default), always and never. For backwards compatibility with earlier versions of the spec, setting withCredentials=true maps to always and withCredentials=false maps to samedomain. But Jonas replied: I'm opposed

Re: Re: Re: [XHR] anonymous flag

[Minor edit: fixed your true/false typo]   * If we had a better way of controlling the option to deny sending credentials in a way that kept compatibility with legacy webpages (eg. a tristate flag like you suggest in [6]), I agree it would be better than to have two different flags which

Re: Re: Re: Re: [XHR] anonymous flag

On Thu, May 23, 2013 at 1:55 AM, Hallvord Reiar Michaelsen Steen   hallv...@opera.com wrote: Given that many services do (mistakenly or not) use Origin and/or Referer to make security choices, all these headers along with the cookie header ought to be considered credentials. Can you

Re: Re: [XHR] anonymous flag

Anne wrote: I don't really feel it's responsible to remove this feature at this point without anyone involved in the original discussion speaking up. Hi all, you were involved in a discussion [1] regarding UMP and CORS back in 2010. I know, it's a while ago, and apparently you had already

Re: Re: [XHR] anonymous flag

BTW - have you considered allowing setting withCredentials to false for same-origin resources? I suspect that would break sites. Possibly, but I find it unlikely - if it's set, it's most likely usually set to true, not false, and it's also most likely rarely set for same-origin

Re: Re: Re: [XHR] anonymous flag

Making a boolean a tri-state with a default depending on an external variable is also super confusing. To whom? It seems confusing to anyone who reads the value. Good point. What would it return in the various situations? I.e. before and after .open() has been called, and if

Re: RE: [XHR] readystatechange for multiple open calls

I just noticed that the topic has been discussed in another thread early this week. Sorry for rushing around after all that. BTW, what was the conclusion? The conclusion is this commit: https://github.com/whatwg/xhr/commit/972797fb12106ca00292b9a2e2cb91d8766c4640 which seems reasonable to

Re: Re: [XHR] anonymous flag

Does anyone have real, non-contrived use cases for the anonymous flag? The basic idea was preventing confused deputy attacks by not exposing any information that could be used as such. So no credentials and no data about where the request originated from, forcing the architecture to be

Re: [XHR] anonymous flag

Yes. It was added to address: http://www.w3.org/TR/UMP/ We could revisit http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/thread.html#msg171 I suppose. Apparently at least Jonas changed his mind since then. I didn't know the UMP spec. Reading it, it seems to me that the

[XHR] question about spec text and tests for double open() calls

Small question regarding these tests: open-send-open.htm open-sync-open-send.htm Test topic: how many readystatechange events are sent if a script in one single script thread does xhr.open(...);xhr.send();xhr.open(...)? Test expectation: one single event, with readyState 1. Both Opera

Re: Re: [XHR] question about spec text and tests for double open() calls

Secondly, by reading the spec I'd expect the second open() call to fire another event. The open() method, steps 15 and 16: 15  Change the state to OPENED. 16  Fire an event named readystatechange. Doesn't imply that if the state is already OPENED, no new event is expected to

[XHR] anonymous flag

If create an anonymous XHR request, rig it to GET a same-origin resource and set a custom header, it will trigger a preflight and the same-origin resource will have to opt in to receiving that custom header? Expected? var xhr=new XMLHttpRequest({anonymous:true}) xhr.open('GET', '/')

Re: [XHR] anonymous flag

Den 8. mai 2013 kl. 17:17 skrev Anne van Kesteren ann...@annevk.nl: On Wed, May 8, 2013 at 5:07 AM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote: If create an anonymous XHR request, rig it to GET a same-origin resource and set a custom header, it will trigger a preflight

Re: Re: [XHR] test nitpicks: MIME type / charset requirements

It seems strange the spec would require a case-sensitive value for Content-Type in certain circumstances. There's only two things that seem to work well over a long period of time given multiple implementations and developers coding toward the dominant implementation (this describes the

[XHR] test nitpicks: MIME type / charset requirements

Two of the tests in http://w3c-test.org/web-platform-tests/master/XMLHttpRequest/send-content-type-string.htm fails in Firefox just because there is a space before the word charset. Aren't both text/html;charset=windows-1252 and text/html; charset=windows-1252 valid MIME types? Should we

Re: Fetch: HTTP authentication and CORS

I had a discussion with Hallvord on IRC about the exact semantics we want for HTTP authentication in the context of CORS (and in particular for XMLHttpRequest, though it would also affect e.g. img crossorigin). So me and Anne have been going a bit back and forth on IRC, we agree on some

Re: Re: Fetch: HTTP authentication and CORS

Here I don't agree anymore. If I want to retrieve a HTTP auth-protected resource with XHR from a CORS-enabled server, the natural thing to do seems to try to pass in the user name and password in the XHR open() call. If the script author supplied user/pass and the server says 401 on a

Re: Re: Re: Fetch: HTTP authentication and CORS

Here I don't agree anymore. If I want to retrieve a HTTP auth-protected resource with XHR from a CORS-enabled server, the natural thing to do seems to try to pass in the user name and password in the XHR open() call. If the script author supplied user/pass and the server says 401

Re: RE: MathML and Clipboard API and events

I suspect that the MathML community would be eager to help define what needs to get stripped out of MathML to maintain security. However, speaking for myself, I do not know what kinds of things are considered dangerous. For example, MathML has markup that lets a math expression act as a

Re: MathML and Clipboard API and events

Hi Paul, thanks for your comments.   Mathematical information   This section says MathML often needs to be transformed to be copied as plain text, for example to make sure to the power of is shown with the caret ^ sign in a formula plain-text input. Such a transformation should not be part of

Re: Clipboard API: Stripping script element

The current clipboard API specification mentions security risks of copy paste but doesn't seem to explicitly mention methods by which user agents deal with such security risks. Hi Ryosuke, I did remove the section on cleaning up content because it was not implemented by anyone and seemed

Re: Re: Clipboard API: Stripping script element

On 03/28/2013 10:36 AM, Hallvord Reiar Michaelsen Steen wrote: In particular, WebKit has been stripping script element from the pasted content but this may have some side effects on CSS rules.] AFAIK (without re-testing right now), WebKit's implementation is: * rich text content

Re: Moving Clipboard API spec forward

Hi Art, slightly late response because I've been away. CCing public-webapps on this reply, in case anyone knows more that should be done. I would like to know your thoughts and plans for the Clipboard API spec.  Here's a short summary as I see it ... * The last publication of Clipboard

Re: Broken Links

There are references to this URL in the Clipboard API and events draft:   http://www.w3.org/TR/html5/dnd.html#the-datatransfer-interface Thanks, seems it should be updated to refer to http://www.w3.org/TR/html5/editing.html#the-datatransfer-interface  I'll get that done, but not today. --

Re: Re: Allow ... centralized dialog up front

On Thu, Jan 31, 2013 at 2:18 PM, Florian Bösch pya...@gmail.com wrote: I would propose to centralize this and make it an up-front dialog remembered for a site such that: That kind of bulk approach does not work. Users don't understand what's going on. To what extent are we sure users

Re: Re: Keyboard events for accessible RIAs and Games

What/where would be a good place to put the API for say queryKeyCap(code) ?   Given that the implementation will have a KeyboardEvent property specified on the global object (i.e. window) I'd propose  window.KeyboardEvent.queryKeyCap(code) which returns a string with the symbol shown on the

Re: Re: CfC: publish WD of XHR; deadline November 29

Are you claiming that the W3C is in the business of plagiarizing? I'm saying that the W3C (and this working group in particular) is taking Anne's work, without his permission, and passing it off as its own. Speaking as one of the W3C-editors of the spec: first I agree that crediting

Re: Re: CfC: publish WD of XHR; deadline November 29

 I would think that listing Anne as Editor or Former Editor and listing Anne in an Acknowledgments paragraph should be entirely consistent with all existing W3C practice. But it's not consistent with that existing W3C practice to get all the text for a spec from a document edited outside the

[XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1

I'm taking a back-channel discussion on-list per Anne's suggestion. We are trying to clarify some text in section 4.6.1, The open() method which is meant to describe how an XMLHttpRequest instance is associated with a specific document. (This association is important for origin checks,

Re: Re: [XHR] Associating XHR instances with documents - clarify spec statement in 4.6.1

Let document be the document associated with the global object of the XMLHttpRequest interface object. You'd also need to check the JavaScript global environment. Thanks for responding. How?   What I mean is that var-variables are scoped to the algorithm they are used in. So you need

Re: Re: Event.key complaints?

I wrote: Hence, what I think would be most usable in the real world would be making event.key a mapping back to un-shifted character values of a normal QUERTY (en-US) layout. Authors are asking for stable reference values for identifying keys, and that's the most stable and widely known

Re: Re: Re: [Clipboard API] The before* events

   It's not only about the context menu (which could be scoped to whatever element was targeted by a right-click), it's also about the Edit menu or the inline commands in Chrome's normal application menu. Enabling the menu entries all the time breaks with existing UI conventions.   But

Re: Re: [Clipboard API] The before* events

  On Thu, Nov 1, 2012 at 5:14 PM, Hallvord Reiar Michaelsen Steen hallv...@opera.com wrote:   The most IMHO elegant solution is what we implemented in Opera: we simply keep relevant menu entries enabled if there are event listeners registered for the corresponding event. This sort of goes

Re: Re: [Clipboard API] The before* events

  It should work just fine if you check the whole eventtarget chain (from the target to the window object). But that means adding a capturing listener on the window would apply this affect to every single element on the page. If that's an acceptable result, then just add the menu item

Re: [Clipboard API] The before* events

Den 1. nov. 2012 kl. 19:38 skrev Ojan Vafai o...@chromium.org: I agree that this use case is not very important and possibly one we shouldn't bother trying to solve. Hallvord's initial point, I think is that there's really no use case for the before* events. We should kill them. Makes it

Re: RE: RE: [XHR] Open issue: allow setting User-Agent?

The point is that a browser can act as if every single server response included Vary: User-Agent.  And perhaps should.  Intermediary caches _certainly_ should. Good suggestion. But my concern was even if browser acts as such, intermediary caches would still return

(aside) MIME type (was Re: Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard)

Hallvord, it should be called media-types btw, or? IMHO the term MIME type is more widely used and also less ambiguous than media type, so I'd definitely prefer using the former if I can get away with it :) -- Hallvord R. M. Steen Core tester, Opera Software

Re: Re: [Clipboard] checking if implementation allows reading/writing a given type to the OS clipboard

Having thought about this some more, I see that there is a fingerprinting concern if we tie this closely into the available applications/OS capabilities. Also I understand that the API would be relevant for drag and drop (thought I'm not quite sure how it would work). Hence I think the method