cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian LeRoux...@brian.io>
Subject Re: InAppBrowser api questions
Date Fri, 23 Nov 2012 12:07:50 GMT
Eh Simon, was just trying to kick the tires using the wiki test page [1]
but always only loads in the webview for me atm. I'm certain I missed
something simple---all I did was create a default project---anything
immediately occur that I might be missing?

[1] http://wiki.apache.org/cordova/InAppBrowserTest


On Thu, Nov 22, 2012 at 9:30 PM, Simon MacDonald
<simon.macdonald@gmail.com>wrote:

> Well, I've got the code mostly implemented there are some things that
> probably can be thrown away or cleaned up a bit (UI, events). I'll probably
> push a version later tonight. All of the manual mobile spec tests are
> working for me.
>
> With regards to the back button, if clicked it closes the InAppBrowser. Why
> you ask? Well the implementation of the ChildBrowser had a hide navigation
> bar parameter and if it was hidden there was no way to dismiss the dialog.
> That's why I'm asking some UI questions as things will need to change just
> a bit.
>
> Simon Mac Donald
> http://hi.im/simonmacdonald
>
>
> On Thu, Nov 22, 2012 at 2:50 PM, Joe Bowser <bowserj@gmail.com> wrote:
>
> > Why do we have the Forward and Back buttons on the browser on Android
> > when Chrome and the Default Browser only have a refresh button? How
> > does this handle the hardware back button? I think we should do what
> > the platform does, except that we don't need multi-tab browsing.
> >
> > On Thu, Nov 22, 2012 at 11:47 AM, Simon MacDonald
> > <simon.macdonald@gmail.com> wrote:
> > > Should the implementation of the InAppBrowser on Android mimic the UI
> of
> > > the iOS app or should it go it's own way?
> > >
> > > Currently the Android ChildBrowser has the buttons and location bar on
> > the
> > > top of the screen. Is there any UI pattern we should be following for
> > this
> > > type of in app browsing?
> > >
> > > Simon Mac Donald
> > > http://hi.im/simonmacdonald
> > >
> > >
> > > On Mon, Nov 19, 2012 at 6:24 PM, Shazron <shazron@gmail.com> wrote:
> > >
> > >> I have a pull request for the JavaScript changes, can someone please
> > >> review: https://github.com/apache/incubator-cordova-js/pull/43
> > >>
> > >> I have committed my InAppBrowser changes to iOS:
> > >>
> > >>
> >
> https://git-wip-us.apache.org/repos/asf?p=incubator-cordova-ios.git;a=commit;h=26a6535c
> > >>
> > >> To test this on iOS right now:
> > >>     cordova.exec(null, null, "InAppBrowser", "open", ["
> > http://google.com",
> > >> "_blank", "location=yes"]);
> > >>
> > >> (don't forget to add InAppBrowser/CDVInAppBrowser to your
> > Cordova.plist).
> > >>
> > >> Note that non-whitelisted URLs cannot be opened in the InAppBrowser
> yet
> > >> because of http://issues.cordova.io/1695 which I am doing next.
> > >>
> > >> Once the js changes are in (at least on ios), you can do:
> > >>    var mywin = window.open("http://www.google.com", "_blank",
> > >> "location=no");
> > >>    mywin.close();
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> On Thu, Nov 15, 2012 at 3:58 PM, Shazron <shazron@gmail.com> wrote:
> > >>
> > >> > I updated the spec: http://wiki.apache.org/cordova/InAppBrowser
> > >> > However, I added the _blank option as well just to be explicit.
> > >> >
> > >> >
> > >> > On Thu, Nov 15, 2012 at 1:58 AM, Shazron <shazron@gmail.com>
wrote:
> > >> >
> > >> >>
> > >> >> I spent some time playing with how to do this.
> > >> >>> 1 - Use referer header - Too many situations result in no
header,
> so
> > >> this
> > >> >>> is out!
> > >> >>> 2 - Use Cookies - if there were a way to have UIWebViews use
> > separate
> > >> >>> cookie jars, this might be feasible. Don't think that's possible.
> > >> >>> 3 - Use User-Agent - this is already suggested in CB-1695.
I also
> > found
> > >> >>> this:
> > >> >>>
> > >> >>>
> > >>
> >
> http://stackoverflow.com/questions/12180224/unique-tab-id-appended-to-user-agent-string-in-chrome-for-ios
> > >> >>> ,
> > >> >>> which suggests that this is what Chrome for iOS uses to implement
> > >> >>> incognito
> > >> >>> mode. If they can make it work, then we should be able to
as well!
> > >> >>>
> > >> >>> So, this is looking like it's non-trivial but not impossible!
As
> > long
> > >> as
> > >> >>> it's possible, let's implement it :)
> > >> >>>
> > >> >>>
> > >> >> Looks like it may be possible in CB-1695 as you mentioned -- so
we
> > can
> > >> >> finish InAppBrowser with this one failing case until it is
> > implemented.
> > >> I
> > >> >> can look into this further once I finish the InAppBrowser
> > integration.
> > >> >>
> > >> >>
> > >> >>> I don't think the semantics of _parent and _blank really map
well
> to
> > >> what
> > >> >>>  we're doing. My vote is to create a new special value: _system,
> and
> > >> only
> > >> >>> this target kicks you out to the system browser.
> > >> >>>
> > >> >>> Also: on the wiki we have:
> > >> >>> [F]  window.open('http://random-url.com', '_blank'); // native
> > browser
> > >> >>>
> > >> >>> It seems weird to me that the effect of _blank changes based
on
> > whether
> > >> >>> the
> > >> >>> URL is in the whitelist. I'd think this case would also open
in
> the
> > >> >>> InAppBrowser.
> > >> >>>
> > >> >>>
> > >> >>> Summary of what I think:
> > >> >>> _self or no target --> open in cordova webview if it's
in the
> > >> Whitelist,
> > >> >>> InAppBrowser otherwise
> > >> >>> _system --> open in system browser
> > >> >>> anything else --> open in InAppBrowser
> > >> >>>
> > >> >>> Also, I like Simon's idea of using the options in window.open
to
> > >> specify
> > >> >>> whether to show URL bar etc. :)
> > >> >>>
> > >> >>
> > >> >> I agree, we need a new value "_system" as you suggested, as well
as
> > the
> > >> >> other parts of the summary of your changes -- makes more sense,
and
> > if
> > >> used
> > >> >> in another context -- it will just work as expected. I can make
the
> > wiki
> > >> >> changes unless others have more comments.
> > >> >>
> > >> >> We can definitely add the window options as well, for sure!
> > >> >>
> > >> >>
> > >> >
> > >>
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message