Re: [whatwg] onclose events for MessagePort

On Tue, Oct 22, 2013 at 1:32 PM, Jonas Sicking wrote: > On Tue, Oct 22, 2013 at 9:31 AM, Ehsan Akhgari wrote: > >> interface MessagePort { > >> ... > >> Promise pin(); > >> void unpin(optional any value); > >> }; > >> > >>

Re: [whatwg] onclose events for MessagePort

On Tue, Oct 22, 2013 at 11:36 AM, Jonas Sicking wrote: > > On Oct 21, 2013 6:08 PM, "Ehsan Akhgari" wrote: > >> How does this work - imagine that I have a reference to a MessagePort, > but I'm not actively waiting for any response on the port so I don't

Re: [whatwg] onclose events for MessagePort

On Mon, Oct 21, 2013 at 3:19 AM, Andrew Wilson wrote: > > > > On Sat, Oct 19, 2013 at 2:26 AM, Jonas Sicking wrote: >> >> >> What I think might work is to say that as long as a "channeldropped" >> event listener is registered with a port, that is equivalent to >> holding a strong reference to th

Re: [whatwg] onclose events for MessagePort

On Fri, Oct 18, 2013 at 8:26 PM, Jonas Sicking wrote: > On Thu, Oct 17, 2013 at 2:08 PM, Ehsan Akhgari wrote: > >> It occurs to me that all of the proposals here does expose some amount > >> of GC behavior. Even a "channeldropped" message which is sent only &

Re: [whatwg] onclose events for MessagePort

On Tue, Oct 15, 2013 at 5:23 AM, Simon Pieters wrote: > On Thu, 10 Oct 2013 17:22:32 +0200, Ehsan Akhgari > wrote: > > Does navigation disentangle ports? I don't think it necessarily does, at >>> least per spec. >>> >> >> >> The cur

Re: [whatwg] onclose events for MessagePort

On Thu, Oct 17, 2013 at 5:08 PM, Ehsan Akhgari wrote: > It occurs to me that all of the proposals here does expose some amount >> of GC behavior. Even a "channeldropped" message which is sent only >> when the other side crashes exposes GC behavior. If GC happens to ru

Re: [whatwg] onclose events for MessagePort

(Sorry for my late reply, this got tangled in my vacation email backlog...) On Thu, Oct 10, 2013 at 5:52 PM, Jonas Sicking wrote: > > The reason I did not extend this to navigation and Worker.terminate() is > > that at least in theory the authors should be able to detect those in > their > > app

Re: [whatwg] onclose events for MessagePort

On Thu, Oct 10, 2013 at 2:58 AM, Jonas Sicking wrote: > On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari wrote: > > OK, so I gave this some thought and I and Olli managed to convince each > > other that finding a solution to the problem of dispatching a generic > > onclos

Re: [whatwg] onclose events for MessagePort

On Thu, Oct 10, 2013 at 4:48 AM, Simon Pieters wrote: > On Thu, 10 Oct 2013 08:58:52 +0200, Jonas Sicking > wrote: > > On Wed, Oct 9, 2013 at 3:06 PM, Ehsan Akhgari wrote: >> >>> OK, so I gave this some thought and I and Olli managed to convince each >>>

Re: [whatwg] onclose events for MessagePort

On Thu, Oct 10, 2013 at 3:11 AM, Andrew Wilson wrote: > > > On Thu, Oct 10, 2013 at 8:58 AM, Jonas Sicking wrote: >> >> >> I could see the GC case not being solvable. >> >> But is there a reason that we couldn't also fire the event if the >> other side is forcefully terminated through a navigati

Re: [whatwg] Possible bug in the way the spec about worker GC behavior

fixes this, and honestly the worker lifetime prose in the spec is very difficult to understand. But I'm more interested to know whether I'm just reading too much into that sentence, or if this is actually what the spec means to say first. Cheers, -- Ehsan <http://ehsanakhgari.org/>

[whatwg] Possible bug in the way the spec about worker GC behavior

Right now the spec says[1] "Whenever a Document object is discarded, it must be removed from the list of the worker's Documents of each worker whose list contains that Document.". If I'm reading this correctly, this implies that the worker object should be alive by the time that the document gets

Re: [whatwg] onclose events for MessagePort

OK, so I gave this some thought and I and Olli managed to convince each other that finding a solution to the problem of dispatching a generic onclose event is impossible since there is no deterministic point in time before a worker is GCed when we know that it will be GCed soon. So with that behin

Re: [whatwg] onclose events for MessagePort

On Tue, Oct 1, 2013 at 1:45 PM, Ian Hickson wrote: > On Tue, 1 Oct 2013, Boris Zbarsky wrote: > > On 10/1/13 12:58 PM, Ian Hickson wrote: > > > If the browser crashes, it's not going to be able to send messages > > > anyway > > > > This concept of "the browser"... > > > > The situation being cons

[whatwg] onclose events for MessagePort

Hi everyone, We're coming across a need to get notified when the other side of a channel goes away because the user navigates away from the page, or if the page is killed by the OS, etc. Currently a workaround is for the application to handle the unload event and send a message on its channel let

Re: [whatwg] UndoManager: Nested transactions and execCommand

I agree that nested transactions are a bad idea, and we probably don't want them. Cheers, -- Ehsan On Mon, Mar 12, 2012 at 2:19 AM, Ryosuke Niwa wrote: > Hi, > > Consider the following scenario: > > > > ... > um1.undoManager.transact({ // transaction 1 > executeAu

Re: [whatwg] Re-introducing AutomaticDOMTransaction interface to decouple automatic transaction from UndoManager

saction to the object creation time, as opposed to when transact is called. I'm not sure if this is a good idea. Cheers, Ehsan - Original Message - > From: "Ryosuke Niwa" > To: "Jonas Sicking" , "Aryeh Gregor" , > "Ehsan Akhgari

Re: [whatwg] Feedback on UndoManager spec

As I mentioned on #whatwg today, I'm fine with this proposal. Cheers, Ehsan - Original Message - > From: "Ryosuke Niwa" > To: "Jonas Sicking" , "Aryeh Gregor" , > "Ojan Vafai" , "whatwg" > , "Ehsan Akhgari&

Re: [whatwg] UndoManager: restoring selection after undoing deletion

> Say you had "hello world" and "world" is deleted by an user. When the > user undoes the deletion, WebKit selects "world" whereas Firefox and > Internet Explorer do not select "world". WebKit's behavior matches > Mac's NSTextView and we probably would like to keep the current > behavior. This con

Re: [whatwg] Undoscopes inside an editable region should ignored

? Could you make the property > ignored in user stylesheets, at least, so that the only way authors > can make things editable is contenteditable/designMode? > > > I wanted to get rid of it but couldn't due to compat. issue. There are > too many applications that d

Re: [whatwg] [editing] New conformance tests

but I have a pretty fast machine!) On Tue, Sep 13, 2011 at 6:25 PM, Ehsan Akhgari wrote: This looks really interesting. Do you think this conformance suite is in a good stage for browser vendors to integrate it in their test suites? I'm interested in integrating this into Mozilla'

Re: [whatwg] [editing] queryCommand(Indeterm|State|Value) for commands where they make no sense

On 11-09-15 4:39 PM, Aryeh Gregor wrote: I think the exception-throwing behavior is preferable in principle, but for compat, I suspect the right behavior is to always return boolean false for state and indeterm, and "" for value. This basically matches everyone but Gecko for commands where none

Re: [whatwg] [editing] New conformance tests

This looks really interesting. Do you think this conformance suite is in a good stage for browser vendors to integrate it in their test suites? I'm interested in integrating this into Mozilla's test suite to make sure that we don't regress anything covered by these tests without realizing it.

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

On 11-09-11 10:00 PM, Ryosuke Niwa wrote: On Tue, Aug 30, 2011 at 12:15 PM, Ryosuke Niwa wrote: 4. Jonas requested that we have manualTransact and managedTransact instead of single transact on undoManager for clarity. I think this is a good idea but I'd rather settle the naming issue first.

Re: [whatwg] Terminology: managed vs. manual transactions

On 11-08-30 12:23 PM, Aryeh Gregor wrote: On Tue, Aug 30, 2011 at 12:12 PM, Ryosuke Niwa wrote: Mn... I've never had that problem. e.g. .net framework uses the term "managed code" to mean the code that's garbage-collected by the framework and "unmanaged code" to mean the code that manually man

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

On 11-08-25 7:06 PM, Ian Hickson wrote: - We need to figure out how UndoManager objects affect the bfcache and the document "salvageable" flag. Please ping me on IRC about this. Would you mind sharing the results of that conversation, please (in case it has happened yet). Thanks! Ehsa

Re: [whatwg] [editing] Additional miscellaneous commands

On 11-08-18 6:09 PM, Bjartur Thorlacius wrote: Þann fim 18.ágú 2011 21:05, skrifaði Alfonso Martínez de Lizarrondo: Now if someone had some bright idea to enable finding in the hidden text that would be perfect, but the view source workaround is good enough for the moment. That seems to be of

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

On 11-08-12 6:10 PM, Ryosuke Niwa wrote: On Fri, Aug 12, 2011 at 3:07 PM, Ehsan Akhgari wrote: On 11-08-09 6:36 PM, Jonas Sicking wrote: Sure, your API is more convenient in certain situations. But it also encourages code duplication (I'll note that in the examples you originally pro

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

On 11-08-09 6:36 PM, Jonas Sicking wrote: On Tue, Aug 9, 2011 at 3:11 PM, Ryosuke Niwa wrote: On Tue, Aug 9, 2011 at 2:55 PM, Jonas Sicking wrote: I don't think it's a matter of which use cases can or can't be solved with either solution. It's pretty clear to me that all scenarios can be solv

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

On 11-08-11 6:07 PM, Jonas Sicking wrote: On Thu, Aug 11, 2011 at 2:56 PM, Ryosuke Niwa wrote: On Thu, Aug 11, 2011 at 2:53 PM, Ehsan Akhgari wrote: I think the confusion is arising because you chose to attach undoManager to elements, not nodes. Note that document _is_ a node in the DOM

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

On 11-08-05 1:01 PM, Ryosuke Niwa wrote: On Fri, Aug 5, 2011 at 9:57 AM, Jonas Sicking wrote: Why treat documentElement specially here? Just make the documentElement *not* have a undoManager by default and have it just use it's ancestor's, just like all other elements. The document is an ance

Re: [whatwg] [editing] Caret Position Access Methods

On 11-07-29 2:14 PM, Ryosuke Niwa wrote: On Fri, Jul 29, 2011 at 11:07 AM, Dan Gisolfi wrote: My point herein and motivation for the suggestion is that this functionality (get/set caret) is available in the textarea element. Using a textarea element you can get/set caret position via get/setSe

Re: [whatwg] getSelection().modify() in vertical writing modes

On 11-06-27 5:30 PM, Ryosuke Niwa wrote: FYI, I also posted this question on public-html-ig...@w3.org, and I got exactly one response from Koji, who was supportive of my proposal. Given that, I'm inclined to say that the consensus is to modify('move', 'left'/'right', 'character') should move the

Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback

On 11-08-06 1:33 AM, Michael[tm] Smith wrote: Aryeh Gregor, 2011-08-04 14:22 -0400: On Wed, Aug 3, 2011 at 5:06 PM, Ehsan Akhgari wrote: Is it possible to get a unique QA contact (or default CC address) for this component please, so that people who are interested in watching it can watch

Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback

Here's my feedback on sections 1-3. I'll provide feedback on the rest of the specification in the near future. 3.2 * The "gecko" prefix should be changed to "moz", to be compatible with other Gecko specific prefixes. * Do we have any other case where the HTML spec says that a browser can chan

Re: [whatwg] [editing] HTML Editing APIs specification ready for implementer feedback

On 11-08-03 4:13 PM, Aryeh Gregor wrote: Mike Smith has been kind enough to add a component to the W3C Bugzilla for the editing spec, in the WebApps WG product. From now on I'll use it for tracking feedback so I can be organized about things that I can't fix right away. The link to file a bug i

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

On 11-08-03 2:55 AM, Anne van Kesteren wrote: On Wed, 03 Aug 2011 00:02:58 +0200, Ehsan Akhgari wrote: By this definition, it's ambiguous what needs to happen to the documentElement's undoScope attribute, since it doesn't have an element ancestor. I think we should just clari

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

On 11-08-02 3:10 PM, Ryosuke Niwa wrote: 1. The definition of @undoscope seems to not address the question of whether the document element should be an Undo Scope or not. Each document has its own undo scope: http://rniwa.com/editing/undomanager.html#undo-scope Sure. What I was specificall

Re: [whatwg] Fixing undo on the Web - UndoManager and Transaction

This is a very nice proposal; thanks for working on this, Ryosuke! I have a number of questions and concerns on it, and I would appreciate if you can comment on these: 1. The definition of @undoscope seems to not address the question of whether the document element should be an Undo Scope or

Re: [whatwg] Handling of collapsed whitespace in contenteditable

On 11-06-20 6:00 PM, Aryeh Gregor wrote: On Mon, Jun 20, 2011 at 5:32 PM, Ehsan Akhgari wrote: There's a very good reason why existing browser engines have to resort to   hacks. It's the only practical way to make sure that "foo__bar" (s/_/ /) entered into an editable elem

Re: [whatwg] Handling of collapsed whitespace in contenteditable

There's a very good reason why existing browser engines have to resort to   hacks. It's the only practical way to make sure that "foo__bar" (s/_/ /) entered into an editable element would appear the intended way when the innerHTML of the editable area is submitted to a server and later display

Re: [whatwg] Request for feedback: supported elements for formatBlock

On 11-05-26 12:27 PM, Aryeh Gregor wrote: I don't think any of this justifies adding blockquote, which is not supported by all browsers and whose *usual* use is to contain multiple blocks of content. It seems to me that "blockquote" here interferes in functionality with the indent and outdent

Re: [whatwg] Request for feedback: supported elements for formatBlock

On 11-05-26 4:40 PM, Aryeh Gregor wrote: I'm still skeptical that no web content depends on blockquote being supported by FormatBlock on WebKit. You might argue that they'll have to modify anyway due to IE not supporting it but most of editors do feature / browser detection and heavily rely on t

Re: [whatwg] Pressing Enter in contenteditable: or or ?

On 11-05-18 2:46 PM, Aryeh Gregor wrote: Also, we should be preserving inline styles. We should copy all attributes and have a blacklist of uncopyable attributes. ID is the only one I can think of off the top of my head that needs blacklisting. accesskey, itemid, and name (on) seem potentially

Re: [whatwg] Pressing Enter in contenteditable: or or ?

On 11-05-13 1:48 PM, Ryosuke Niwa wrote: On Fri, May 13, 2011 at 10:26 AM, Aryeh Gregorwrote: Note that br and div affect UBA differently so we must consider what bidirectional text users want as well. For example, if we hadhello, and inserted br as in hello, then we preserve the RTL directional

Re: [whatwg] Pressing Enter in contenteditable: or or ?

On 11-05-13 1:26 PM, Aryeh Gregor wrote: If you're going to add pretty-printing, doesn't it make more sense to just add the text nodes directly to the DOM? You're going to have to deal with the extra nodes anyway as soon as the content round-trips to a server. We're not going to add pretty-pri

Re: [whatwg] Pressing Enter in contenteditable: or or ?

On 11-05-13 2:25 PM, Boris Zbarsky wrote: I just tested innerHTML, and I found it stripped the attribute, but it didn't seem to add any whitespace around,, or. innerHTML uses OutputRaw which ensures that no prettyprinting happens ever, no matter what, even if a gun is held to the serializer's h

Re: [whatwg] Pressing Enter in contenteditable: or or ?

his is the way we want to behave, then I'll also > have commands normalize nearby s to s where it makes things > easier, like I normalize other types of markup. I think we want to keep using s, but I'm not convinced if is a better choice than . Cheers, -- Ehsan Akhgari eh...@mozilla.com http://ehsanakhgari.org/

Re: [whatwg] selection.modify behavior across platforms

illa bug: > <https://bugzilla.mozilla.org/show_bug.cgi?id=496275>. I get the > impression there are actual use-cases for *something* resembling this > feature, I just haven't figured out what they are . . . Here's a possible use case: https://bugzilla.mozilla.org/show_bug.cgi?id=496275#c10 -- Ehsan Akhgari eh...@mozilla.com http://ehsanakhgari.org/

Re: [whatwg] selection.modify behavior across platforms

t return different values depending on platforms. Do you know more details on this? Which commands have this platform specific behavior? And why does Webkit do different things on different platforms here? Cheers, -- Ehsan Akhgari eh...@mozilla.com http://ehsanakhgari.org/

Re: [whatwg] selection.modify behavior across platforms

the underlying platform, which makes web authors automatically expect that from all APIs, which may cause unexpected surprises if the author doesn't test their application in all platforms. Don't you think that is a problem which we should address somehow? -- Ehsan Akhgari eh...@mozilla.com http://ehsanakhgari.org/

Re: [whatwg] selection.modify behavior across platforms

points out that its results are platform specific. Otherwise, it's just too easy to assume that the result of calling this API is the same across all platforms, just like almost all other Web APIs. Cheers, -- Ehsan Akhgari eh...@mozilla.com http://ehsanakhgari.org/

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

> I always felt it had valid use-cases in *some* form -- namely, some > authors want conforming content, which means no , while some > authors want markup that will work in crippled HTML processors like > Blackberry's e-mail client, which means they want . The only > question was whether there was

[whatwg] selection.modify behavior across platforms

Hi all, Usually, when the user is using the keyboard to extend or move the selection in a document, the result of the keyboard commands vary depending on the underlying platform. For example, on Windows, word selection "eats spaces" in between words. That is, if you have "f|oo bar" (the pip

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

ot that much of an > improvement in this very simple case, the effect is obvious when the > applied on more complicated markup. This makes quite a bit of sense. -- Ehsan Akhgari eh...@mozilla.com http://ehsanakhgari.org/

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

- Original Message - > From: "Robert O'Callahan" > To: "Ehsan Akhgari" > Cc: "Aryeh Gregor" , "whatwg" > , "Ryosuke Niwa" , > "Ehsan Akhgari" , "Hallvord R. M. Steen" > > Sent: Monday, Mar

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

- Original Message - > From: "Aryeh Gregor" > To: "Ehsan Akhgari" > Cc: "whatwg" , eh...@mozilla.com, "Hallvord R. M. > Steen" , "Ryosuke Niwa" > > Sent: Monday, March 21, 2011 1:25:40 PM > Subject: Re: [whatwg] On

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

ult. I haven't made up my mind on this one yet... > Gecko and WebKit both honor it, but in >> >> substantially different ways. E.g., with styleWithCSS on, Gecko will >> output something likeFoo if you bold >> a paragraph, while WebKit will output something like> style="font-weight: bold">Foo. >> > > In my opinion, they're equivalent and consistent enough although it's nice > to agree on which DOM to produce. I agree with Ryosuke here as well. -- Ehsan Akhgari Mozilla Corporation http://ehsanakhgari.org/

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

r. A lot of the complexity of Gecko's implementation in these cases is caused by the desire to generate simpler DOM structures as much as possible, and the type of resulting structure would also have an effect on the algorithms (simple example: the unstyling algorithm needs to handle all those tricky cases). -- Ehsan Akhgari Mozilla Corporation http://ehsanakhgari.org/

Re: [whatwg] Ongoing work on an editing commands (execCommand()) specification

structures should be preferred, and we can't give away simple DOM structures for the sake of simpler algorithms. Browsers tend to have buggier behavior when it comes to editing more complex DOM structures, and one should also keep in mind that editing operations are additive: having one command generate a complex DOM would cause the next one to generate even more complex DOM, and so on. Cheers, -- Ehsan Akhgari Mozilla Corporation http://ehsanakhgari.org/