Public bug reported:
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.
** Affects: oxide
Importance: Medium
Status: Triaged
** Changed in: oxide
Importance: Undecided => Medium
** Changed in: oxide
Status: New => Triaged
** Description changed:
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.
+ 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.
** Description changed:
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).
+ - 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.
--
You received this bug notification because you are a member of Ubuntu
WebApps bug tracking, which is subscribed to Oxide.
https://bugs.launchpad.net/bugs/1666866
Title:
Stop continuously updating WebView::editingCapabilities
Status in Oxide:
Triaged
Bug 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). 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.
To manage notifications about this bug go to:
https://bugs.launchpad.net/oxide/+bug/1666866/+subscriptions
--
Mailing list: https://launchpad.net/~ubuntu-webapps-bugs
Post to : ubuntu-webapps-bugs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ubuntu-webapps-bugs
More help : https://help.launchpad.net/ListHelp
