Re: [webkit-dev] Proposal to Reorganize Position Classes
Just for context: Maciej and others had some feedback in the similar Rich Text Editing Questions, Refactoring of Position Class thread from a year ago (4/2/10). As an aside, I'm wondering if the general thoughts and reservations about supporting positions inside :before/:after-generated content and multiple ranges has changed in the meantime (?). A few more comments (questions, rather) inline: On Wed, Feb 2, 2011 at 11:51 AM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, * * *While I'm not intending to write a patch for the following proposal anytime soon, I'd really like to get your feedback.* * * As you might all know, Position classes in WebCore need refactoring and cleanup. Part of it is due to legacy editing positions that do many magics, and we're currently in the process of removing them (see the bug 52099 http://webkit.org/b/52099). However, even if we didn't have legacy editing positions, we still have rather clattered code base - there are many global functions in visible_units.cpp and VisiblePosition is used all over in WebCore/rendering - and reorganization of Position-related classes is needed (see the bug 52098 http://webkit.org/b/52098). I spent the last couple months to figure out what's the right solution and realized that there are generally two use cases of VisiblePosition: - To differentiate upstream/downstream to express caret positions - To iterate through editable regions to implement editing commands For the former use case, triggering layout or respecting editing boundary is not needed at all, and the use of VisiblePosition seems an overkill. I concluded that these two use cases should be addressed by two different classes. So I propose to implement the following 3 classes in lieu of the existing Position and VisiblePosition: - *DOMPosition* or *SimplePosition* - This class solely works on DOM, and is agnostic of renderers and other parts of WebCore. It's meant to be used in utility functions and classes or passed along between renderers and WebCore/dom. It doesn't know anything about upstream or downstream. - *RenderedPosition* - This positions is an enhanced version of the current Position. It represents every possible visible position and or DOM position and communicates vocabularies between WebCore/rendering and WebCore/editing. It knows about line boundary and upstream/downstream but it doesn't trigger a layout, doesn't canonicalize, and doesn't know anything about editing boundary. Its life-time is tied to layout cycle, and needs to be re-created every time DOM mutation or style change occurs. Many functions in visible_units.cpp can belong to this class as member functions. Furthermore, PositionIterator could be merged into this class because RenderedPosition can cache pointers and other invariants as needed since RenderedPosition's lifetime is tied to layout cycle. It can also share some code with TextIterator as well. How does RenderedPosition know line boundaries and upstream/downstream if it doesn't trigger layout? - *EditingPosition* or *VisiblePosition* - This class is almost identical to the existing VisiblePosition. It knows everything DOMPosition and RenderedPosition knows, and respects editing boundary. A significant difference with VisiblePosition is that this class remembers the editable root element to which it belongs. So when crossing editing boundary, it can figure out whether or not we're still inside the same root editable root or not. It also knows how to canonicalize itself so editing commands can canonicalize positions as needed although canonicalization could be optional. I'm also not sure if this class should trigger a layout inside its constructor like VisiblePosition does or not yet. A significant difference with VisiblePosition... - do you mean vs. RenderedPosition or vs. the current VisiblePosition? The introduction of RenderedPosition is particularly useful in rendering engine because it allows to express any caret/insertion point position with a guarantee that it doesn't trigger a layout. Not triggering layout is certainly a good point and something that should bring quite a bit of performance. However, I wonder some of this functionality shouldn't be factored out in a separate non-Position class (say SelectionManager). Cheers, - Roland ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] safari extension script loading within injected file
This list is for discussion of the development of the WebKit project itself, not questions about how to use WebKit (or a browser that uses WebKit, such as Safari). See http://webkit.org/contact.html for details. You'll have better luck asking in a Safari-specific venue, such as https://devforums.apple.com/community/safari. -Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] svn.webkit.org and nightly.webkit.org down ahead of schedule?
Hi Bill- svn.webkit.org is responding to pings, but svn up just hangs. And nightly.webkit.org responds to pings, but never finishes loading when navigated to in a browser. Is this expected? Do you know when they'll be available again? Thanks! -Adam On Feb 1, 2011, at 8:52 PM, William Siegrist wrote: We are upgrading another server tomorrow morning at 7am PST. Downtime should be about an hour and I will make announcements in #webkit as usual. Mail delivery to @webkit addresses and mailing lists will not happen during the downtime, but mail should catch up once we come back up. Affected services are: build.webkit.org git.webkit.org lists.webkit.org nightly.webkit.org Thanks -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] svn.webkit.org and nightly.webkit.org down ahead of schedule?
Svn and nightly have been fixed. The maintenance is still planned for 7am this morning. -Bill On Feb 2, 2011, at 5:05 AM, Adam Roben wrote: Hi Bill- svn.webkit.org is responding to pings, but svn up just hangs. And nightly.webkit.org responds to pings, but never finishes loading when navigated to in a browser. Is this expected? Do you know when they'll be available again? Thanks! -Adam On Feb 1, 2011, at 8:52 PM, William Siegrist wrote: We are upgrading another server tomorrow morning at 7am PST. Downtime should be about an hour and I will make announcements in #webkit as usual. Mail delivery to @webkit addresses and mailing lists will not happen during the downtime, but mail should catch up once we come back up. Affected services are: build.webkit.org git.webkit.org lists.webkit.org nightly.webkit.org Thanks -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] device element
Hello Safari, Recently I read about the device element in the HTML specification. It seems the possibilities of such an element wourld improve a browsers features sigificantly. Since the device element is not implemented in any browser yet, is Safari already planning to implement this? Link to device element: http://www.whatwg.org/specs/web-apps/current-work/complete/commands.html#devices Regards,Rene NEU: FreePhone - kostenlos mobil telefonieren und surfen!Jetzt informieren: http://produkte.web.de/go/webdefreephone ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] device element
Hi René, There's already people working on this in WebKit. I can't speak about Safari but we're actually discussing different approaches to its implementation. Please take a look at this thread and feel free to contribute: https://lists.webkit.org/pipermail/webkit-dev/2011-January/015822.html Regards, Leandro El 2 de febrero de 2011 14:16, René Müller mueller.re...@web.deescribió: Hello Safari, Recently I read about the device element in the HTML specification. It seems the possibilities of such an element wourld improve a browser´s features sigificantly. Since the device element is not implemented in any browser yet, is Safari already planning to implement this? Link to device element: http://www.whatwg.org/specs/web-apps/current-work/complete/commands.html#devices Regards, Rene NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: *http://produkte.web.de/go/webdefreephone*http://produkte.web.de/go/webdefreephone ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Server Downtime - Feb 2nd, 7 - 8am PST
All services are back online. Let me know if you have any trouble with them. -Bill On Feb 1, 2011, at 5:52 PM, William Siegrist wrote: We are upgrading another server tomorrow morning at 7am PST. Downtime should be about an hour and I will make announcements in #webkit as usual. Mail delivery to @webkit addresses and mailing lists will not happen during the downtime, but mail should catch up once we come back up. Affected services are: build.webkit.org git.webkit.org lists.webkit.org nightly.webkit.org Thanks -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the device element
I have created a patch to introduce compilation guards for the device element implementation. These should be the same independently of the design approach we decide to take while enabling us to propose more specific patches later. Here's the link: https://bugs.webkit.org/show_bug.cgi?id=53595 Thanks, Leandro El 1 de febrero de 2011 01:43, Leandro Graciá Gil leandrogra...@chromium.org escribió: Hi, We have recently noticed a patch to implement the device element in WebKit. Since this is an important new feature, I thought we should have a discussion about the best way to implement it. Here's the actual specification for it: http://www.whatwg.org/specs/web-apps/current-work/complete/commands.html#devices . The approach proposed in https://bugs.webkit.org/show_bug.cgi?id=47264 brings the device probing and selection to the WebCore level. It does so by first creating a list of available devices using an interface to a platform-dependent client and then it passes this list to a client dialog to perform the actual selection from it. With its current design both operations are performed synchronously, possibly blocking the device element event handler for a long time. I think this is not a suitable design. Given the drawbacks of the approach above, I would like to propose an alternative design that solves these issues. First of all, we think that is not necessary at all to bring the device probing, available device lists, device selection or connection to WebCore. The device element isn't really about actual devices, but about connecting to them. We think that it would be the best for all platforms to actually delegate the actual probing, selection and connecting to them in an asynchronous client-based model and hold only connection and handler information in WebCore. Here's an example of the call flow in our proposal: 0. The device element is created in a no connection state and with an empty device connection descriptor. 1. User clicks the device element (a button, for example). 2. The device element changes its internal state from no connection to connecting, and asks to the device controller to connect to a device of its type sending also the document security origin. 3. The device controller, which handles and maps all the device requests of the page, forwards the connection request to the device page client. This client is implemented by the corresponding WebKit platforms. 4. The device client receives the request and, in a non-blocking way, implements the way it likes the device probing, selection, connecting and all the required security operations (the latter also missing in the existing patch). This allows every UA vendor to make their own choices about the UI for device selection. 5. When the platform has finished connecting to a device, it sends back to the device controller a device connection update message. This message comes with a device connection descriptor that contains the actual connection status, error codes/messages, device ids/names if connected and so on. In case of user cancelation, connection or communication error the same message is sent, but with different device connection descriptor values. 6. The device controller forwards the message to the original device element. The original element sets its connection descriptor to the received object and changes its state accordingly. It will change to connected if the connection was successful or to not connected in case of error. It will also fire the appropriate JS events. 7. If the connection was successful, the element will then create valid stream objects from its data attribute. These will not contain any real streaming data but just a url string. All the actual data is internally managed by the platforms, leaving only handler-like objects in WebCore. The url can be provided for the moment with the connection descriptor object, being later replaced by some type-independent object when device types other than media are defined. Requesting to disconnect the device would work much like requesting a connection, but providing the device descriptor object as a parameter instead. With this approach, not only we avoid to block WebCore with potentially long operations but we provide a great flexibility to all WebKit platforms to implement the nasty device handling details as they want to. This should also potentially increase the amount of code that can be reused by the different platforms, while avoiding any list matching code that can be found in the existing patch. I have a patch that implements this design, but I wanted to get some feedback on this list before sending it out for review. Please don't hesitate to make any suggestions that could help to improve this. Thanks, Leandro ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Implementing the device element
I have created a patch to introduce compilation guards for the device element implementation. These should be the same independently of the design approach we decide to take while enabling us to propose more specific patches later. Here's the link: https://bugs.webkit.org/show_bug.cgi?id=53595 Thanks, Leandro PS: sorry if you received this twice. I used the wrong account before and it seems that it wasn't properly reported as a thread reply in the list archive. El 1 de febrero de 2011 01:43, Leandro Graciá Gil leandrogra...@chromium.org escribió: Hi, We have recently noticed a patch to implement the device element in WebKit. Since this is an important new feature, I thought we should have a discussion about the best way to implement it. Here's the actual specification for it: http://www.whatwg.org/specs/web-apps/current-work/complete/commands.html#devices . The approach proposed in https://bugs.webkit.org/show_bug.cgi?id=47264 brings the device probing and selection to the WebCore level. It does so by first creating a list of available devices using an interface to a platform-dependent client and then it passes this list to a client dialog to perform the actual selection from it. With its current design both operations are performed synchronously, possibly blocking the device element event handler for a long time. I think this is not a suitable design. Given the drawbacks of the approach above, I would like to propose an alternative design that solves these issues. First of all, we think that is not necessary at all to bring the device probing, available device lists, device selection or connection to WebCore. The device element isn't really about actual devices, but about connecting to them. We think that it would be the best for all platforms to actually delegate the actual probing, selection and connecting to them in an asynchronous client-based model and hold only connection and handler information in WebCore. Here's an example of the call flow in our proposal: 0. The device element is created in a no connection state and with an empty device connection descriptor. 1. User clicks the device element (a button, for example). 2. The device element changes its internal state from no connection to connecting, and asks to the device controller to connect to a device of its type sending also the document security origin. 3. The device controller, which handles and maps all the device requests of the page, forwards the connection request to the device page client. This client is implemented by the corresponding WebKit platforms. 4. The device client receives the request and, in a non-blocking way, implements the way it likes the device probing, selection, connecting and all the required security operations (the latter also missing in the existing patch). This allows every UA vendor to make their own choices about the UI for device selection. 5. When the platform has finished connecting to a device, it sends back to the device controller a device connection update message. This message comes with a device connection descriptor that contains the actual connection status, error codes/messages, device ids/names if connected and so on. In case of user cancelation, connection or communication error the same message is sent, but with different device connection descriptor values. 6. The device controller forwards the message to the original device element. The original element sets its connection descriptor to the received object and changes its state accordingly. It will change to connected if the connection was successful or to not connected in case of error. It will also fire the appropriate JS events. 7. If the connection was successful, the element will then create valid stream objects from its data attribute. These will not contain any real streaming data but just a url string. All the actual data is internally managed by the platforms, leaving only handler-like objects in WebCore. The url can be provided for the moment with the connection descriptor object, being later replaced by some type-independent object when device types other than media are defined. Requesting to disconnect the device would work much like requesting a connection, but providing the device descriptor object as a parameter instead. With this approach, not only we avoid to block WebCore with potentially long operations but we provide a great flexibility to all WebKit platforms to implement the nasty device handling details as they want to. This should also potentially increase the amount of code that can be reused by the different platforms, while avoiding any list matching code that can be found in the existing patch. I have a patch that implements this design, but I wanted to get some feedback on this list before sending it out for review. Please don't hesitate to make any suggestions that could help to improve this. Thanks, Leandro
Re: [webkit-dev] Server Downtime - Feb 2nd, 7 - 8am PST
Mailing list delivery was broken until now, but most services were back around 8am. Sorry for the inconvenience. -Bill On Feb 2, 2011, at 8:10 AM, William Siegrist wrote: All services are back online. Let me know if you have any trouble with them. -Bill On Feb 1, 2011, at 5:52 PM, William Siegrist wrote: We are upgrading another server tomorrow morning at 7am PST. Downtime should be about an hour and I will make announcements in #webkit as usual. Mail delivery to @webkit addresses and mailing lists will not happen during the downtime, but mail should catch up once we come back up. Affected services are: build.webkit.org git.webkit.org lists.webkit.org nightly.webkit.org Thanks -Bill ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Proposal to Reorganize Position Classes
On Wed, Feb 2, 2011 at 3:16 AM, Roland Steiner rolandstei...@google.comwrote: Just for context: Maciej and others had some feedback in the similar Rich Text Editing Questions, Refactoring of Position Class thread from a year ago (4/2/10). As an aside, I'm wondering if the general thoughts and reservations about supporting positions inside :before/:after-generated content and multiple ranges has changed in the meantime (?). I don't think we're supporting multiple ranges anytime soon. But it should be orthogonal to this discussion because multiple ranges are tied to selection, not to positions. One of the motivations to do this refactoring was bugs related to first-letter. I think in the ideal world, we can isolate all code that deals with before, after, and first-letter inside RenderedPosition so that the rest of editing code doesn't need to know about them. - *RenderedPosition* - This positions is an enhanced version of the current Position. It represents every possible visible position and or DOM position and communicates vocabularies between WebCore/rendering and WebCore/editing. It knows about line boundary and upstream/downstream but it doesn't trigger a layout, doesn't canonicalize, and doesn't know anything about editing boundary. Its life-time is tied to layout cycle, and needs to be re-created every time DOM mutation or style change occurs. Many functions in visible_units.cpp can belong to this class as member functions. Furthermore, PositionIterator could be merged into this class because RenderedPosition can cache pointers and other invariants as needed since RenderedPosition's lifetime is tied to layout cycle. It can also share some code with TextIterator as well. How does RenderedPosition know line boundaries and upstream/downstream if it doesn't trigger layout? It assumes that the renderers are up-to-date. Just like you must be triggering layout before accessing renderer from nodes, you must trigger layout manually prior to creating a RenderedPosition. - *EditingPosition* or *VisiblePosition* - This class is almost identical to the existing VisiblePosition. It knows everything DOMPosition and RenderedPosition knows, and respects editing boundary. A significant difference with VisiblePosition is that this class remembers the editable root element to which it belongs. So when crossing editing boundary, it can figure out whether or not we're still inside the same root editable root or not. It also knows how to canonicalize itself so editing commands can canonicalize positions as needed although canonicalization could be optional. I'm also not sure if this class should trigger a layout inside its constructor like VisiblePosition does or not yet. A significant difference with VisiblePosition... - do you mean vs. RenderedPosition or vs. the current VisiblePosition? With the existing current VisiblePosition. The introduction of RenderedPosition is particularly useful in rendering engine because it allows to express any caret/insertion point position with a guarantee that it doesn't trigger a layout. Not triggering layout is certainly a good point and something that should bring quite a bit of performance. However, I wonder some of this functionality shouldn't be factored out in a separate non-Position class (say SelectionManager). I don't quite get what you mean here. Could you elaborate? - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] code review tool changes
On Tue, Feb 1, 2011 at 5:09 PM, Ojan Vafai o...@chromium.org wrote: -Side-by-side diffs: You can view the entire diff or individual files in side-by-side diff. If you change the entire diff, we'll store that in localstorage and load diffs in side-by-side by default. -Comments and diff navigation: n/p keys will navigate to the next/previous comment. j/k will navigate to the next/previous diff. -Draft comments persist: draft comments are now stored in localstorage, so they will persist across reloads, crashes, etc. Since it's in localstorage it's stored per-machine.* -Expand diff context: You can expand the lines above/below a diff to see more context.** Hope this works well for you all. Obviously, file bugs if something isn't working. On Tue, Feb 1, 2011 at 6:07 PM, Ojan Vafai o...@chromium.org wrote: Forgot one. Comments from the style checker are also shown in the code review tool now. These are great features. Being able to quickly switch between unified diffs and side-by-side diffs has been very useful. Thanks for the improvements. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] safari extension script loading within injected file
On Tue, Feb 1, 2011 at 5:44 PM, Nick Guenther nick.guent...@dossierview.com wrote: Cluestick (or n00b question): What's 'document' within the extension scope? It is not the same as 'document' of the loaded page. I am no expert with terminology here, so in case that makes zero sense: If I load up a web page and use the debugger to print window.document, it is different from the window.document that I get when I breakpoint on the injected javascript. I made a simple test where I load a single javascript file from within the injected js. This single file creates a variable, window.MyGlobal. What is very interesting to me is that this object is accessible from the loaded page! Meaning if I create an html file that tries to access window.MyGlobal, it can. I don't think web page authors are supposed to be able to access variables created by extensions. I'm going to pose the question in the Apple list Adam suggested. I'll post the solution here for completeness when I get one. Lou ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] safari extension script loading within injected file
On Wed, Feb 2, 2011 at 10:59 PM, Lou Zell lzel...@gmail.com wrote: I made a simple test where I load a single javascript file from within the injected js. This single file creates a variable, window.MyGlobal. What is very interesting to me is that this object is accessible from the loaded page! Meaning if I create an html file that tries to access window.MyGlobal, it can. I don't think web page authors are supposed to be able to access variables created by extensions. After giving this more thought. This behavior does seem perfectly reasonable. The javascript I'm using (in the first email) loads the second script by appending a script tag to head. So obviously whatever is in that script is going to be accessible by the page's author. I'm going to pose the question in the Apple list Adam suggested. I'll post the solution here for completeness when I get one. So, it appears the answer to my question is: you're doing it wrong! Any javascript that my extension needs must be injected in. I can specify multiple files to inject, but I was trying to only load files as I needed them--instead of injecting them all on each page load. In the future I can imagine Apple adding some form of conditional injection to extensions. Best, Lou ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
