Index ¦ Archives ¦ RSS > Category: collabora-online ¦ RSS

Improved copy & paste in Collabora Online: the copy side

Estimated read time: 4 minutes

Collabora Online now uses the Clipboard API if it's available in the used browser, getting rid of many annoying dialogs.

Motivation

The paste side was covered by an earlier post, but in short, if you're on Chrome (or Safari), you won't see the "can't paste" dialog:

"Can't paste" dialog in COOL 23.05

Also you won't see a "Can't paste special" dialog:

"Can't paste special" dialog in COOL 23.05

Wouldn't it be nice to improve the copy side in a similar way?

Results so far

The primary reason why we needed similar, annoying dialogs for copy in the past is that the clipboard API was synchronous but the network API is async. This means that writing to the clipboard ("copy") is only possible with data that we have in the browser when the copy is executed. This is a problem, since in general we don't have data for your selection in the browser.

With the Clipboard API, the copy side can be improved as well. Instead of always fetching the HTML for a simple selection (even if you don't copy) and having a three step copy for complex selections, async clipboard write is now possible. This gets us rid of the "You need to download" dialog:

"You need to download" dialog in COOL 23.05

Also it eliminates the "Download completed dialog:

"Download completed" dialog in COOL 23.05

Instead, we still need to nominally write to the clipboard in the special keyboard or click context initiating the copy (Chrome doesn't require this, Safari does), but the written object can be a callback that will do the network operation for us.

Unfortunately it's hard to screenshot the new code, since part of the result is that all these dialogs are now eliminated, copy & paste just works. :-)

Note that this can be used also in Firefox, but first you need to set dom.events.asyncClipboard.clipboardItem to true in about:config.

The last part was to adapt tests to this new world, because previously it was handy to just create a selection and assert what would be copied to the clipboard as HTML, but now we don't download the HTML anymore every time you create a selection.

How is this implemented?

If you would like to know a bit more about how this works, continue reading... :-)

As usual, the high-level problem was addressed by a series of small changes:

The tracking issue was cool#8648.

Want to start using this?

You can get a development edition of Collabora Online 24.04 and try it out yourself right now: try the development edition.


Effecting code review and backporting for Collabora Online

Estimated read time: 3 minutes

Collabora Online now has a ./g script that tries to bring some of the Gerrit-based review benefits to a workflow based on GitHub.

Motivation

Collabora Online is on GitHub, but core.git is still on Gerrit, so it made sense to spend some time on a small shell script that gives you review and backport experience that is closer to Gerrit than the stock GitHub workflow.

How we use GitHub

Most Online committers push their code for review directly to online.git, to private namespaced branches, like private/kendy/master, then a pull request can be created to get commits from that branch into master after CI, review, etc. This workflow has the benefit that you don’t have to deal with the complexity of multiple repos.

Next to master, there are distro branches like distro/collabora/co-6-4, we may or may not want to backport the contents of a PR to that stable branch.

It’s important that Gerrit used to have a git review command to just submit your changes for review, without asking anything. That explains why the stock GitHub workflow where you need to name the source branch of your PR feels unnecessary complexity. Creating the PR by visiting a webpage is again something we want to avoid. Not to mention open questions like should you delete your source branch after a PR is merged? Should you delete your source repo?

On the other hand, we’re interested in GitHub’s ability to have multiple commits in a PR: Gerrit forces to have one commit per change. The GitHub way encourages developers to split changes into more commits, now that the review and CI cost won’t increase just due to such splits.

Submit for review

The happy path is when you have one or more local commits and you want to submit it for review. In this case now you can do:

./g review

And the script will figure out that you want to push your local branch to a remote branch like private/kendy/master and also create a pull request for you, printing its URL.

In case that branch already exists then you need to specify a name:

./g review myhack

So parallel reviews are possible, but only the first gets an inferred name. Both cases need no clicking in a browser, thanks to gh.

Submit a backport

The easiest case is when you can assume that the master branch and the distro branch is so close to each other that there won’t be conflicts to be resolved. In that case, you can do:

./g backport distro/collabora/co-6-4 790

to pick all commits from PR 790 (which is already merged to master) to a distro branch.

Again, you can have multiple backports in progress, e.g. you can do:

./g backport distro/collabora/co-6-4 790 myhack

If the default name is already used. The backport syntax is a bit longer, so you can always just type ./g backport and you’ll get the usage.

This second command is a bit more complicated, as gh has no trivial way to expose what is the commit range of a PR. But there is gh api graphql which can do arbitrary GraphQL queries, which provide this information. At this stage it may make sense to just rewrite the whole ./g script in e.g. Python, but till that happens, we parse the output of the query using jq.

Finally, if you do have conflicts or you want a local build test / manual test before submitting, you can always check out the distro branch manually, cherry-pick there and use plain ./g review to submit your backport for review.

Want to start using this?

You can go to the Collabora Online community website and see how to build the code. Then you may want to solve an easy hack, finally submit your commit for review either by using the above method or whichever way you prefer contributing to GitHub projects.

© Miklos Vajna. Built using Pelican. Theme by Giulio Fidente on github.