cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wargo, John" <>
Subject RE: [Android] InAppBrowser sucks and needs a re-write
Date Tue, 21 Jan 2014 14:33:29 GMT
Part of the weirdness is that insertCSS and executeScript have callbacks and nothing else does.
Plus options is a string rather than an object like it is in every other API. IAB just doesn't
feel like a Cordova plugin. +1 to refactoring it so it looks, feels and works like the other
Cordova APIs.

We use IAB in our solution, so would like to see it stick around. It adds some very useful
capabilities to our plugins and it is better to have the community support it than to have
to write our own. 

John M. Wargo
Twitter: @johnwargo

-----Original Message-----
From: Jesse [] 
Sent: Tuesday, January 21, 2014 8:22 AM
Subject: Re: [Android] InAppBrowser sucks and needs a re-write

InAppBrowser is important to windows phone too.
Oauth would be difficult/unpossible without it.

I agree some of the recent additions to the api don't make a tonne of sense.
Namely: insertCSS and executeScript are strange additions that seemed
to be added out of nowhere?!
The fact that we chose to override and change the
behaviour completely never made sense to me, but I was planning on
just releasing my own Browser plugin that works the way I think it
should, and the way I want it to. I would much rather see us write
competing cross-platform plugins than try to agree on what the api
should be.

We definitely need this functionality, even on Android, as there is an
extra level of control we get by having our own control.

Sent from my iPhone

> On Jan 21, 2014, at 4:58 AM, Brian LeRoux <> wrote:
> Eh Joe, lets tone down 'X sucks' and stick to dispassionate evaluations of
> technology. I get the usefulness of the shortcut, and tend to agree, but it
> isn't constructive.
> Is oAuth workflow not possible w/ vanilla intents?
>> On Mon, Jan 20, 2014 at 11:05 AM, Joe Bowser <> wrote:
>> Let me clarify:
>> 1. OAuth sucks, and InAppBrowser sucks, and there's no better solution
>> to this problem, so InAppBrowser will probably have to stay
>> 2. Does anyone disagree with me when I say that InAppBrowser sucks and
>> is too complex.  If so, why?
>> 3. Who wants to re-write the code that I don't care about?
>> On Mon, Jan 20, 2014 at 11:01 AM, Darryl Pogue <>
>> wrote:
>>> As Shazron mentioned, it is important for apps doing OAuth with
>>> 3rd party services that might not provide Java APIs.
>>> In our case, we need to use InApp Browser to allow users to sign in
>>> to FitBit. We detect when the URL changes after a successful login and
>>> pull tokens from it.
>>>> On Mon, Jan 20, 2014 at 10:55 AM, Brian LeRoux <> wrote:
>>>> The only platform that really needs it is iOS b/c it doesn't have
>> intents
>>>> so I'm not sure focusing on this part of the codebase is a worthwhile
>>>> exercise. I'd be fine with deprecating the Android support and add a
>> docs
>>>> note for ppl to not hijack href's for spawning in-app when running
>> anywhere
>>>> but iOS.
>>>>> On Mon, Jan 20, 2014 at 10:37 AM, Joe Bowser <>
>>>>> Hey
>>>>> So, after spending a bit of time with InAppBrowser, I think we should
>>>>> get rid of it.  It serves almost no purpose, and it's way too complex
>>>>> of a plugin for us to maintain.  However, nobody would agree with me
>>>>> about shitcanning this thing, so instead I propose we re-write the
>>>>> whole thing because it pretty much needs to be green-fielded.
>>>>> Part of the reason is the fact that the UI is all hardcoded when it
>>>>> doesn't need to be.  Now that we're moving around resources, we should
>>>>> be able to move around XML layouts and use this instead of hardcoding
>>>>> our UI in JS.
>>>>> The other part of the reason is that I think that too many new
>>>>> features got added to InAppBrowser, and I don't think anyone actually
>>>>> knows how this thing is supposed to work.  Furthermore, I think that
>>>>> on Android, even if you follow Android guidelines, the InAppBrowser
>>>>> looks totally stupid and it screams "This is a PhoneGap App therefore
>>>>> it sucks!".  If our users can tell if an app is written in Cordova, we
>>>>> have failed.
>>>>> Now, I'm fine with moving out the UI, but I want to know how much
>>>>> people care about this stupid plugin.
>>>>> Also, on another note, has anyone tried starting Chrome with
>>>>> startActvitiyForResult and onActivityResult? I'd much rather have
>>>>> chrome appear and have Chrome pass the results back than our stupid
>>>>> half-baked browser.
>>>>> I'm sure everyone has thoughts on this, so let's hear them.
>>>>> Joe

View raw message