| 2017-02-22 11:30:09 |
Chris Coulson |
description |
Updating WebView::editingCapabilities isn't cheap if the clipboard selection owner changes because we need to read data from the clipboard to update the paste bit. This used to be a bigger problem, although it was improved significantly by caching clipboard status.
However, as part of bug 1666002, we're going to be refreshing WebView::editingCapabilities from more callbacks. This is wasteful, and I'd prefer we just stopped doing it.
In addition to this, CanUndo and CanRedo are always unset, because there is currently no visibility of this on the browser side and no way to get notifications for them from blink.
What we should do is:
- Stop continuously updating WebView::editingCapabilities.
- Add a new method to WebView to trigger an asynchronous refresh of the WebView::editingCapabilities. property. Applications can call this when displaying a UI that requires it (such as a window menu).
- Refresh WebView::editingCapabilities when displaying the touch editing UI, to avoid breaking what looks like the only consumer of this API in webbrowser-app. |
Updating WebView::editingCapabilities isn't cheap if the clipboard selection owner changes because we need to read data from the clipboard to update the paste bit. Previous experience suggests this can take >100ms in some cases. This used to be a bigger problem, although it was improved significantly by caching clipboard status.
However, as part of bug 1666002, we're going to be refreshing WebView::editingCapabilities from more callbacks. This is wasteful, and I'd prefer we just stopped doing it.
In addition to this, CanUndo and CanRedo are always unset, because there is currently no visibility of this on the browser side and no way to get notifications for them from blink.
What we should do is:
- Stop continuously updating WebView::editingCapabilities.
- Add a new method to WebView to trigger an asynchronous refresh of the WebView::editingCapabilities. property. Applications can call this when displaying a UI that requires it (such as a window menu).
- Refresh WebView::editingCapabilities when displaying the touch editing UI, to avoid breaking what looks like the only consumer of this API in webbrowser-app. |
|
| 2017-02-22 11:31:35 |
Chris Coulson |
description |
Updating WebView::editingCapabilities isn't cheap if the clipboard selection owner changes because we need to read data from the clipboard to update the paste bit. Previous experience suggests this can take >100ms in some cases. This used to be a bigger problem, although it was improved significantly by caching clipboard status.
However, as part of bug 1666002, we're going to be refreshing WebView::editingCapabilities from more callbacks. This is wasteful, and I'd prefer we just stopped doing it.
In addition to this, CanUndo and CanRedo are always unset, because there is currently no visibility of this on the browser side and no way to get notifications for them from blink.
What we should do is:
- Stop continuously updating WebView::editingCapabilities.
- Add a new method to WebView to trigger an asynchronous refresh of the WebView::editingCapabilities. property. Applications can call this when displaying a UI that requires it (such as a window menu).
- Refresh WebView::editingCapabilities when displaying the touch editing UI, to avoid breaking what looks like the only consumer of this API in webbrowser-app. |
Updating WebView::editingCapabilities isn't cheap if the clipboard selection owner changes because we need to read data from the clipboard to update the paste bit. Previous experience suggests this can take >100ms in some cases. This used to be a bigger problem, although it was improved significantly by caching clipboard status.
However, as part of bug 1666002, we're going to be refreshing WebView::editingCapabilities from more callbacks. This is wasteful, and I'd prefer we just stopped doing it.
In addition to this, CanUndo and CanRedo are always unset, because there is currently no visibility of this on the browser side and no way to get notifications for them from blink.
What we should do is:
- Stop continuously updating WebView::editingCapabilities.
- Add a new method to WebView to trigger an asynchronous refresh of the WebView::editingCapabilities. property. Applications can call this when displaying a UI that requires it (such as a window menu). This will perform a renderer round trip to get the undo/redo capabilities from blink.
- Refresh WebView::editingCapabilities when displaying the touch editing UI, to avoid breaking what looks like the only consumer of this API in webbrowser-app. |
|
