[FEATURE REQUEST] "Open in Web" for native clients

[pmaier1]

Story
As a client user I want to open a file in the Web Office directly from the context menu so that I can easily start collaborating with others

Specifics

• Infinite Scale only
• Use App provider backend
• Timeline ~ mid August

@hosy @felix-schwarz

[felix-schwarz]

@pmaier1

1. Should Web Office open in Safari - or in an in-app browser?
2. Is there already an ocis or Web Office API for this?

[felix-schwarz]

If integration with external/add-on web services is something that should be available across clients, it could IMO make sense to have a dedicated ocis API for this that:

• provides a list of available services for an item
• mediates access and integration

[pmaier1]

Should Web Office open in Safari - or in an in-app browser?

Default browser app, I'd say. Definitely not the in-app browser.

Is there already an ocis or Web Office API for this?

Yes, oCIS has the app provider for this. More information can be provided e.g., by @wkloucek

[hosy]

Should Web Office open in Safari - or in an in-app browser?

Default browser app, I'd say. Definitely not the in-app browser.

Why not in-app browser (or as option)? I think it could be also interesting to do not lose the focus or to have it in a container app.

[wkloucek]

Is there already an ocis or Web Office API for this?

Yes, oCIS has the app provider for this. More information can be provided e.g., by @wkloucek

It's described here: https://owncloud.dev/extensions/app-registry/apps. If you miss something I'll be happy to add that.

[wkloucek]

Should Web Office open in Safari - or in an in-app browser?

Default browser app, I'd say. Definitely not the in-app browser.

Why not in-app browser (or as option)? I think it could be also interesting to do not lose the focus or to have it in a container app.

We should also reuse the session. Don't know if there is a limitation in the integrated or default browser.

[pmaier1]

Why not in-app browser (or as option)? I think it could be also interesting to do not lose the focus or to have it in a container app.

Coming from a use case perspective, I think I'd find it rather weird to make some last minute changes in a presentation in the in-app browser. Having separate browser open feels somewhat more solid, I think. But maybe I just need to see it in action.

[felix-schwarz]

Is there already an ocis or Web Office API for this?

Yes, oCIS has the app provider for this. More information can be provided e.g., by @wkloucek

It's described here: https://owncloud.dev/extensions/app-registry/apps. If you miss something I'll be happy to add that.

Thanks, that looks good @wkloucek!

One note on opening in an in-app browser vs. in Safari/Chrome/… however. Under Open a file with the app provider, there's this example of a response:

{
  "app_url": "https://.....",
  "method": "POST",
  "form_parameters": {
    "access_token": "eyJ0...",
    "access_token_ttl": "1634300912000",
    "arbitrary_param": "lorem-ipsum"
  }
}

It's only possible to open simple URLs in Safari/Chrome/… on iOS. Which results in the browser using the GET method to load the page at the URL.

It's not possible to open a URL in a browser using a POST method - or to pass along any cookies or Authorization tokens. That's only possible using an in-app browser.

The difference in user experience should be marginal. At least on iPadOS it would be possible to open it in a separate "scene" (think "window") that could be used side-by-side just like one could with two different apps.

/cc @pmaier1

[pmaier1]

The difference in user experience should be marginal. At least on iPadOS it would be possible to open it in a separate "scene" (think "window") that could be used side-by-side just like one could with two different apps.

Ah ok, thanks. In that case I'd leave this up to you to decide. In-app browser seems like the way to go.

[pmaier1]

Any update? cc @michaelstingl @dragotin

[michl19]

@michaelstingl Ich schließ' mich der Frage an. What's the status and what can we show for the testing system?

[michaelstingl]

Backend update: owncloud/client#9724 (comment)

[felix-schwarz]

App provider support is implemented by #1151, but I noticed a few rough edges in actual usage when using the open-in-web endpoint:

1. The web UI chrome is visible on top, looking like a toolbar, making it easy to navigate away from the document.
2. The search field of the web UI chrome could be mistaken by users as a search button for the document
3. Tapping the back button brings up an error message, but doesn't bring me back to the app.
4. It's easy to zoom by mistake via a double tap.
5. The browser chrome takes up space and could be confusing to users.
6. Navigation back to the iOS app requires switching the app. Closing the document requires multiple taps in the browser chrome.
7. It's not clear to the user how they save changes or when/if they are saved automatically.

Possible remedies:

• add parameters to the open-in-web endpoint for
  • hiding the web UI chrome on top?
  • a returnURL that the back button links to, f.ex. owncloud://?
• add code to the HTML page's <head> to disable zooming?
• use the open endpoint instead and show the web app in an in-app browser instead?

[wkloucek]

Possible remedies:

• add parameters to the open-in-web endpoint for

  • hiding the web UI chrome on top?
  • a returnURL that the back button links to, f.ex. owncloud://?

• add code to the HTML page's <head> to disable zooming?

• use the open endpoint instead and show the web app in an in-app browser instead?

@kulmann could you check if that's possible?

[kulmann]

Possible remedies:

• add parameters to the open-in-web endpoint for
  • hiding the web UI chrome on top?

We could add a query param embed=true and provide an application layout (for reference: talking about a new layout web-runtime/src/layouts/Embed.vue which hides the web UI chrome.

• a returnURL that the back button links to, f.ex. owncloud://?

Is the returnURL supported via the app provider? If yes, then we can easily forward that. Otherwise needs to be implemented in the app provider first.

• add code to the HTML page's <head> to disable zooming?

Yes, but would like to wire that to a query param as well (or use the embed=true for it).

• use the open endpoint instead and show the web app in an in-app browser instead?

That's not a question in my direction I guess :-)

[wkloucek]

I asked OnlyOffice about the back button (if configurable). Answer pending

[wkloucek]

We could add a query param embed=true and provide an application layout (for reference: talking about a new layout web-runtime/src/layouts/Embed.vue which hides the web UI chrome.

That would be great.

Yes, but would like to wire that to a query param as well (or use the embed=true for it).

I think a separate parameter would be fine.

We can add both parameters hardcoded here https://github.com/owncloud/ocis/blob/08a8ed20c18a1d5344cec78c4f72e61bee71c878/services/frontend/pkg/revaconfig/config.go#L102-L112. But then they apply to all clients using the /app/open-with-web endpoint.

[felix-schwarz]

I added support for displaying the web app in-app and it fixes some of the issues.

I also added a mode in which the in-app browser has a button to open the document in the default browser.

In-app	In-app, with default browser option

[felix-schwarz]

I noticed issues on the [confidential] test instance when I edit documents:

• the entire personal space (in which the document resides) temporarily disappears from the spaces list, comes back when the changes have been saved
• I can no longer edit a document that I edited previously that way:

@wkloucek Is there anything I should call on the server or in the web app's JS context to "close" the web app session? At the moment, the web view is just terminated, so there probably is also no event being sent to the web app's JS part.

[wkloucek]

I noticed issues on the [confidential] test instance when I edit documents:

• the entire personal space (in which the document resides) temporarily disappears from the spaces list, comes back when the changes have been saved
• I can no longer edit a document that I edited previously that way:

We had a bug on that instance that is now fixed. Could you please try again if you can reproduce this issue?

@wkloucek Is there anything I should call on the server or in the web app's JS context to "close" the web app session? At the moment, the web view is just terminated, so there probably is also no event being sent to the web app's JS part.

Just closing is sufficient. It will take a few seconds before OnlyOffice saves the file and closes it. In the meantime it is locked and therefore can not be opened.

[felix-schwarz]

@wkloucek I can confirm that this issue no longer occurs.