Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

As a WebWorks developer, I can support displaying content in a child web view of my application #230

Closed
kwallis opened this Issue · 50 comments

9 participants

@kwallis
Owner

Background

Web content often attempts to open content in a new window using the _blank target. This use case needs to be supported within the WebWorks application context

Acceptance Criteria

  • both declarative (eg. ) and programmatic (window.open) attempts to open content in target _blank should open this content in a child webview of the application.
  • targets _self, _top, _parent should replace the content in the main application content webview.
  • Child web views will have a title bar displaying the page title.
  • The child web view title bar will include a Close button that will close the child web view.
  • Child web views opened in this way should not have access to WebWorks apis
  • Child webviews should be enabled by default.
    • The developer can choose to disable child views through the config.xml
    • If disabled, new "window" requests should be sent to the browser application
    • eg.
<feature id="blackberry.app">
<param id="childBrowser" value="disable" />
</feature>
  • Use cases that should be enabled and work correctly with this implementation are as follows:
    • facebook login dialog
    • Oauth and Oauth2 (eg. Twitter, Google APIs)
  • TBD: items required to be added to config.xml, if any, to support the general case of opening child views
@kwallis
Owner

@cdelcol @nukulb Please review

@cdelcol

Can we say explicitly that the FB auth must work?
https://developers.facebook.com/docs/authentication/client-side/

I'd like to list any auths that we want to support, and specify what if anything needs to be added to the config.xml. For example, FB has to access connect.facebook.net/en_US/all.js, but doesn't specify exactly how it creates the window. you just call FB.login().

As a developer, i'd expect that adding <access> for connect.facebook.net would mean this is now completely functional.

@nukulb

better oauth and oauth2 should work

@kwallis
Owner

Updated

@jeffheifetz

This issue does not discuss the UX of a child webview at all.

I assume it acts like an overlay and that it has some minimal chrome (containing at least a back button and perhaps a refresh button?) Perhaps we should model the header to be similar to unbound invocation UI? Should it animate in ?

@kwallis
Owner
@jeffheifetz

I don't believe we should support such a complicated chrome no matter what our webview event gives us or what the browser supports. It will greatly complicate the feature and be inconsistent with the same child webview when invoked slightly differently.

@nukulb

Stretch goal for this -
@jeffheifetz I would like to see API support in this as well, few things will have to be done to make this happen

Have a networkResource requested for each webview.
The network resource requested will pass the ID of the Webview to the API
When an event occurs the API will pass the ID of the webview to the eventing framework
Eventing framework will execute on specific Webview

Obviously an API will have to keep track of which API has come from which webview.


A simpler version or a compromise is when an sync API is executed but when an event occurs it fires it off in all webviews and lets it error out for some webviews

Really don't like this though.

@kwallis
Owner
@nukulb
@kwallis
Owner
@nukulb

maybe, I think it will be a lot of work to expose them anyways but want to jeff to be aware of where this is going

@jeffheifetz

@nukulb Thanks for the heads up, so the stretch goal is to have it impose the same whitelisting rules as the client webview, correct?

@kwallis What should happen for subsequent requests to open a window? I don't like the idea of multiple childWebViews, so the two reasonable options in my eyes are to either redirect the current childWebView (not a big deal since it will have a chrome with a back button) or to have it open in the browser (a moderately bizarre user experience).

@nukulb

@jeffheifetz - yes. basically qnx auto wants to run one massive webworks app that has 10 qebworks apps in it with a single massive config.xml

@kwallis
Owner
@jeffheifetz

@kwallis I'm not sure, since I don't really now how a qebworks app would work.

As per UI of the chrome, would we prefere controls on the top similair to unbound invocation list, or on the bottom more like an action bar?

@nukulb
@derek-watson

I've successfully tested Facebook logins as recommended by the documentation, with the following caveats:

  1. The Javascript SDK FB.login() method requires the app be hosted on a domain that is whitelisted in your Facebook developer account.
  2. The Client-Side Authentication method can be run from locally-hosted content, but requires the application developer host a page on a whitelisted domain which Facebook will redirect a successful login to, which in turn will redirect the user back to local://.

I can provide test applications for both scenarios, each including

  • A WebWorks app
  • A server-side component (to be run on a whitelisted domain)
  • Instructions for configuring a Facebook Application

At the very least this will need to be clearly documented with examples and so on so developers know how to get around all these hurdles.

@jeffheifetz

@ctetreault I know you have an app with facebook integration as a sample already, does it make sense for you to simply expand it to show the client side authentication methods? Or atleast that we use the same domains and app tokens?

@ctetreault

I tried to get a client-side flow to work in a nice way with WebWorks but it never played nice. @derek-watson doesn't that approach require you to have the facebook "login" button somewhere in your app, or can you have them connect to facebook automatically?

I personally like the server side flow best because it seems a little more autonomous from a ui perspective. The user clicks on a menu item for example, the app does it's communicating with facebook, and done.

@jeffheifetz

So previously I'm not sure client side could have been completed, especially not the FB.login way.

This feature adds support for this method specifically, so I'd like to have an example of it, even if it is perhaps more intrusive.

@ctetreault

Sorry, just to get up-to-speed here, we're talking about using a "childbrowser"/"webview" whatever it's called now? ;)

@derek-watson

@ctetreault I don't think there's a clean way to have the app automatically authenticate with Facebook, using the client-side flow anyway. For the first login, you either need to perform a redirect or launch a popup. Launching a popup (childWebview) cannot be done without a user click (due to popup blocking in webkit), so you're correct about the need for a FB login button somewhere in the app.

@jeffheifetz Correct, the FB.login() SDK method uses window.open from the app webview and window.close from the childWebview, so this is now possible, if somewhat convoluted by the need for an external whitelisted domain.

@nukulb

@jeffheifetz - couple of questions about this

  1. Where is this at right now? Is there something we are waiting for now?
  2. You need to include calling webworks APIs from multiple webview into this, have you done that already?
  3. I have not seen any API docs for this, what is the user going to call?
@jeffheifetz

There are no API docs atm, as there are no APIs. There is simply the ability to have childWebViews when a browser would open a new window or tab. I suppose we could offer some APIs related to either eventing or closing the childWebView, but these are not currently discussed.

As per the code, there is a working implementation but its being rebased off of the UI elements change to webplatform.

I'd like to split the webworks APIs into a separate feature seeing as they feel independent to me.

@jeffheifetz jeffheifetz referenced this issue in blackberry-webworks/BB10-WebWorks-Framework
Closed

implemented child webview #195

@jeffheifetz

Based on conversations in the API pull request, we will be implementing the following changes.

WindowOpen events from the child webview will be invoked in the browser.

An API will be added in the blackberry.ui.childWebview with an enable/disable feature.

@nukulb

@jeffheifetz - will the api be declarative like orientation or background or actually a traditional javascript call?

@jeffheifetz

@kwallis @nukulb What would you guys prefer. Do you see developer demand to enable/disable on the fly?

@kwallis
Owner
@jeffheifetz

Sounds good to me, the only thing I would push for is to make it blackberry.ui.childwebview

@nukulb
@kwallis
Owner
@nukulb
@jeffheifetz

We do not have a namespace, currently there is no API at all.

@kwallis
Owner
@nukulb
@jeffheifetz

But doesn't that enforce people to include blackberry.app when they may not want to?

@nukulb

they have to already for background.

@jeffheifetz

If thats what you and @kwallis want and there's a precedent we'll do it, but it feels bizarre to me

@kwallis
Owner
@kwallis
Owner

Updated description. Based on our earlier discussion, I still do not see why we would need enable/disable child web view?

@jeffheifetz

Agreed, I believe that is no longer necessary

@nukulb

We still need an enable disable with this feature. There are customers that don't have control over their content and want to always invoke the browser.
We need an enable/disable, can't force everyone to use this.

I am proposing enabled by default and it can be disabled through

<feature id="blackberry.app" >
<param id="childBrowser" value="disable" />
</feature>

If no one uses it I don't think we have lost anything.

@kwallis
Owner

OK. updated description

@derek-watson

Params are supposed to have names and not ids, so the config block will look like this instead:

<feature id="blackberry.app" >
<param name="childBrowser" value="disable" />
</feature>

@nukulb
@derek-watson derek-watson referenced this issue in blackberry-webworks/BB10-Webworks-Packager
Closed

Added support for disabling childBrowser (childWebView) behaviour #102

@derek-watson derek-watson referenced this issue from a commit in blackberry-webworks/BB10-WebWorks-Framework
@derek-watson derek-watson This commit adds support for ChildWebViews to be opened through links
with a blank target or the window.open JS function.

Fixes issue blackberry/BB10-WebWorks-Framework#230

All logic into webplatform, Framework refers to the blackberry.app.childBrowser configuration setting
to enable or disable the functionality.

Reviewed By: Jeffrey Heifetz <jheifetz@rim.com>
Tested By: Igor Shneur <ishneur@rim.com>
7b694a0
@derek-watson derek-watson referenced this issue from a commit in blackberry-webworks/BB10-Webworks-Packager
@derek-watson derek-watson added blackberry.app childBrowser param config as per the childWebVie…
…w spec

also updates the framework hash.

Fixes blackberry/BB10-WebWorks-Framework#230

Reviewed By: Jeffrey Heifetz <jheifetz@rim.com>
Tested By: Igor Shneur <ishneur@rim.com>
9b57e01
@jeffheifetz

Shipped.

@ybqin

hi, can you help me that how to delete the title bar and the Close button at the child web view ?
i don't need them

@varunasingh

If I am moving from index.html in webworks to page.html using window.open, then how can I do so having page.html access to Webworks apis and getting rid of the blue title bar / header with Close button ?

Reason to why I am doing window.open() is because I want to load the page again, such that it refreshes and the apis get called again.
This way seems to work fine in Android, iOS, Windows Phone 8

Thoughts ?

Edit: Sorry, my bad I got it working. I did this:

window.open('page.html', '_self');

this comment will dismantle

@astanley

on BlackBerry 10, window.open() invokes a childbrowser window, of which you cannot configure the default close button.

If you want to reload the page in the current frame, use window.location.href = 'page.html';

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.