Re: [DISCUSS] Keep or Remove Disqus from Blog

[kevin]

Hey Team!

If you did want to fix it, I’d be happy to monitor it (providing I get 
notifications) and then prompt people to redirect bug reports to GitHub.

It’ll show other devs thinking of using Cordova that the project is still 
actively monitored and developed.

Let me know!
On 2 Nov 2024 at 09:37 +, Niklas Merz , wrote:
> I'm also in favor of removing Disqus because of the monitoring issue. We
> just cant keep track of those comments.
>
> Redirecting the users to Github discussion sounds like the best
> approach.
>
> On November 2, 2024, Erisu  wrote:
> > Our website used to display a Disqus commenting section at the bottom
> > of
> > each blog post, allowing readers to leave comments.
> >
> > It appears that this feature stopped working about nine months ago
> > (based
> > on the date of the last comment).
> >
> > While inspecting the developer tools as the website loaded, I noticed
> > that
> > two resource files were failing to load because they are missing from
> > the
> > `frame-src` directive in the Content Security Policy.
> >
> > I wanted to raise the following questions:
> >
> > - Do we want to fix and continue supporting Disqus on our blog posts?
> > - Do we want to discontinue support and remove Disqus?
> > - Has anyone actively monitored or reviewed the comments posted on
> > Disqus
> > while it was still functioning on the site?
> >
> > Personally, I am in favor of removing Disqus from the website. I
> > haven’t
> > actively monitored blog comments to see what was being discussed. Some
> > users were raising issues and making requests in the comments, but I
> > believe these should be posted on our GitHub repositories. General
> > discussions could also be moved to the Discussions tab of our Cordova
> > repo.
> >
> > There may be solutions for integrating GitHub Discussions into the
> > blog
> > posts as an alternative to Disqus, though this would require
> > additional
> > investigation.
> >
> > If we decide to keep Disqus, I’ll update the Content Security Policy
> > to
> > include the two missing resource files and proceed from there.

Re: Moving on

[Kevin Whinnery]

Hat tip Fil, excellent work on the tools.  Hope you love your new gig!


On Fri, Aug 30, 2013 at 2:45 PM, Giorgio Natili wrote:

> Good luck!!!
>
> Sorry for the brevity, Sent from my iPhone
>
> On Aug 30, 2013, at 9:31 PM, Jesse  wrote:
>
> > Best of luck Fil!
> > Hope the new gig is everything you want!
> > Take the keg-erator as a parting gift, if anyone asks, just say I said it
> > was okay.
> >
> > Cheers,
> >  Jesse
> >
> > @purplecabbage
> > risingj.com
> >
> >
> > On Fri, Aug 30, 2013 at 12:14 PM, Brian LeRoux  wrote:
> >
> >> Wherein I wish I could favstar an email.
> >>
> >> Truth hurts Gord!
> >> On Aug 30, 2013 12:13 PM, "Gord Tanner"  wrote:
> >>
> >>> Oh that is low Michal ;)
> >>>
> >>> Don't make me walk the 2 blocks to break my foot off in your ass.
> >>>
> >>>
> >>> On Fri, Aug 30, 2013 at 2:58 PM, Michal Mocny 
> >> wrote:
> >>>
> >>>> Bah!  Nonsense!  Inconceivable!
> >>>>
> >>>> You will be missed, Fil, but do have fun in your new adventure.
> >>>>
> >>>> Also, speak up more often than Gord here on this lists, will ya? ;)
> >>>>
> >>>> -Michal
> >>>>
> >>>>
> >>>> On Fri, Aug 30, 2013 at 2:50 PM, Max Woghiren 
> >> wrote:
> >>>>
> >>>>> Best of luck, Fil!
> >>>>>
> >>>>>
> >>>>> On Fri, Aug 30, 2013 at 2:48 PM, Gord Tanner 
> >>> wrote:
> >>>>>
> >>>>>> Best of luck dude!
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Aug 30, 2013 at 2:45 PM, Filip Maj 
> >>> wrote:
> >>>>>>
> >>>>>>> Sweet, glad there are volunteers willing to take on stuff right
> >>> away!
> >>>>>>>
> >>>>>>> And yes: I've got my phonegapday EU ticket and will be booking
> >>> travel
> >>>>>> this
> >>>>>>> weekend. Hopefully I'll see most of you there!
> >>>>>>>
> >>>>>>> P.S. who's going to lxjs? I'm going to be there along with a few
> >>> good
> >>>>>> folk
> >>>>>>> from the Adobe Cordova team :)
> >>>>>>>
> >>>>>>>
> >>>>>>> On Fri, Aug 30, 2013 at 11:42 AM, Ian Clelland <
> >>> iclell...@google.com
> >>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Best of luck, Fil!
> >>>>>>>>
> >>>>>>>> Glad to hear you're not stepping away from the project
> >> entirely,
> >>>> but
> >>>>>> your
> >>>>>>>> CLI and Plugman efforts will be missed, for sure.
> >>>>>>>>
> >>>>>>>> Will we still see you at PGDay?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Fri, Aug 30, 2013 at 2:33 PM, Lucas Holmquist <
> >>>>> lholm...@redhat.com
> >>>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> good luck dude
> >>>>>>>>> On Aug 30, 2013, at 2:31 PM, Filip Maj 
> >>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hey everyone,
> >>>>>>>>>>
> >>>>>>>>>> Wanted to let the community know that I'm moving on from
> >>> Adobe.
> >>>>>>> Tuesday
> >>>>>>>>>> I'll be starting at Saucelabs, working on mobile automation
> >>> on
> >>>>> the
> >>>>>>> R&D
> >>>>>>>>> team.
> >>>>>>>>>>
> >>>>>>>>>> My focus is going to shift away from cordova a little bit,
> >>> but
> >>>>> not
> >>>>>>>>>> entirely. My plan is to be involved a lot more in
> >>> cordova-medic
> >>>>>>> moving
> >>>>>>>>>> forward, but stepping away from the tooling (plugman +
> >> cli),
> >>>> JS,
> >>>>>> spec
> >>>>>>>> and
> >>>>>>>>>> platform work.
> >>>>>>>>>>
> >>>>>>>>>> As such, I'll be removing myself as "lead" in JIRA on the
> >>>>>> cordovaJS,
> >>>>>>>>>> mobile-spec, cli and plugman components. If any committers
> >>> want
> >>>>> to
> >>>>>>> step
> >>>>>>>>> up
> >>>>>>>>>> and take on a more involved role on those components, I'd
> >>>>> recommend
> >>>>>>>>>> assigning yourself as lead in JIRA to those, that's always
> >> an
> >>>>> easy
> >>>>>>> way
> >>>>>>>> to
> >>>>>>>>>> be intimately familiar with issues coming down the pipeline
> >>> :)
> >>>>>>>>>>
> >>>>>>>>>> Looking forward to working more on medic with you all!
> >>>>>>>>>>
> >>>>>>>>>> Cheers,
> >>>>>>>>>> Fil
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
>



-- 
*
 Kevin Whinnery
@kevinwhinnery
 http://kevinwhinnery.com
*

Re: CDVViewController.commandDelegate

[Kevin Hawkins]

Not beyond the twitch, no. :) The current de facto implementation works for
our uses.  The latter (header) issue was honestly the first time I'd
noticed, doing a code review where "#import CDVCommandDelegateImpl.h" was
being added to my view controller's .m file, and I didn't understand why.

I can file and fix it, either way. Would you all prefer the property type
switch, or simply fixing the header imports?  The only risk I see around
the property change is the fact that it's public interface, so could
generate warnings (errors?) at compile time, for people upgrading their
existing projects.

Cheers,
Kevin



On Wednesday, February 20, 2013, Michal Mocny wrote:

> Thanks for mentioning this.  Would you like to file that bug and/or submit
> a pull request?
>
> Also, do you have some motivating reason for moving to a "more
> protocol-based property"?  I understand your twitch, but am curious if you
> are trying to replace with another implementation?
>
> -Michal
>
> On Tue, Feb 19, 2013 at 7:59 PM, Kevin Hawkins <
> kevin.hawkins.cord...@gmail.com > wrote:
>
> > Hi all,
> >
> > I'm looking through the CDVViewController implementation details on iOS,
> > and I'm not clear why its (public) commandDelegate property references
> the
> > concrete implementation class of the CDVCommandDelegate protocol
> > (CDVCommandDelegateImpl), as opposed to defining a more generic
> > protocol-based property.  From an object-oriented design standpoint,
> that's
> > something I didn't expect.  Is there a reason that this is different than
> > CDVPlugin's property definition?
> >
> > It's not a super big deal, though it sets off something twitchy in my
> > brain. ;-)  What does need to change if it stays as-is, however, is that
> > CDVViewController.h should be #importing CDVCommandDelegateImpl.h, not
> > CDVCommandDelegate.h.  The way it is currently, the responsibility of the
> > former header's inclusion is being improperly passed on to the inheriting
> > view controller class.  And the latter header file's inclusion is
> > superfluous.
> >
> > I figured I'd get thoughts before filing a bug one way or another.
> >
> > Thanks,
> > Kevin
> >
>

Re: CDVViewController.commandDelegate

[Kevin Hawkins]

Thanks guys.  I'll file a bug, and should have a pull request shortly.
 Andrew, for the record, I didn't see anything particular in Jira around
public symbols maintenance, from a cursory search.

Cheers,
Kevin


On Wed, Feb 20, 2013 at 8:42 AM, Andrew Grieve  wrote:

> Would definitely be better to expose that property as a protocol. That's
> the whole point of having the protocol in the first place :P.
>
> I forget if I created a bug for it yet, but cutting down on the number of
> public symbols is definitely a TODO for both iOS and Android codebases.
>
>
> On Wed, Feb 20, 2013 at 11:17 AM, Kevin Hawkins <
> kevin.hawkins.cord...@gmail.com> wrote:
>
> > Not beyond the twitch, no. :) The current de facto implementation works
> for
> > our uses.  The latter (header) issue was honestly the first time I'd
> > noticed, doing a code review where "#import CDVCommandDelegateImpl.h" was
> > being added to my view controller's .m file, and I didn't understand why.
> >
> > I can file and fix it, either way. Would you all prefer the property type
> > switch, or simply fixing the header imports?  The only risk I see around
> > the property change is the fact that it's public interface, so could
> > generate warnings (errors?) at compile time, for people upgrading their
> > existing projects.
> >
> > Cheers,
> > Kevin
> >
> >
> >
> > On Wednesday, February 20, 2013, Michal Mocny wrote:
> >
> > > Thanks for mentioning this.  Would you like to file that bug and/or
> > submit
> > > a pull request?
> > >
> > > Also, do you have some motivating reason for moving to a "more
> > > protocol-based property"?  I understand your twitch, but am curious if
> > you
> > > are trying to replace with another implementation?
> > >
> > > -Michal
> > >
> > > On Tue, Feb 19, 2013 at 7:59 PM, Kevin Hawkins <
> > > kevin.hawkins.cord...@gmail.com > wrote:
> > >
> > > > Hi all,
> > > >
> > > > I'm looking through the CDVViewController implementation details on
> > iOS,
> > > > and I'm not clear why its (public) commandDelegate property
> references
> > > the
> > > > concrete implementation class of the CDVCommandDelegate protocol
> > > > (CDVCommandDelegateImpl), as opposed to defining a more generic
> > > > protocol-based property.  From an object-oriented design standpoint,
> > > that's
> > > > something I didn't expect.  Is there a reason that this is different
> > than
> > > > CDVPlugin's property definition?
> > > >
> > > > It's not a super big deal, though it sets off something twitchy in my
> > > > brain. ;-)  What does need to change if it stays as-is, however, is
> > that
> > > > CDVViewController.h should be #importing CDVCommandDelegateImpl.h,
> not
> > > > CDVCommandDelegate.h.  The way it is currently, the responsibility of
> > the
> > > > former header's inclusion is being improperly passed on to the
> > inheriting
> > > > view controller class.  And the latter header file's inclusion is
> > > > superfluous.
> > > >
> > > > I figured I'd get thoughts before filing a bug one way or another.
> > > >
> > > > Thanks,
> > > > Kevin
> > > >
> > >
> >
>

Re: Jira issues to the mailing list

[Kevin Hawkins]

Ah, somehow I missed that step when I changed email accounts.  Thanks Shaz!

On Wednesday, February 20, 2013, Shazron wrote:

> Isn't it refreshing? Subscribe to iss...@cordova.apache.org now.
>
> On Wednesday, February 20, 2013, Kevin Hawkins wrote:
>
> > Does anyone else not get JIRA bugs copied to the mailing list anymore, or
> > is that just me?  I used to get them, but then my Cordova mailing list
> > behavior has always been a little flaky.
> >
> > Thanks,
> > Kevin
> >
>

Re: Jira issues to the mailing list

[Kevin Hawkins]

Ah, somehow I missed that step when I changed email accounts.  Thanks Shaz!

On Wednesday, February 20, 2013, Shazron wrote:

> Isn't it refreshing? Subscribe to iss...@cordova.apache.org now.
>
> On Wednesday, February 20, 2013, Kevin Hawkins wrote:
>
> > Does anyone else not get JIRA bugs copied to the mailing list anymore, or
> > is that just me?  I used to get them, but then my Cordova mailing list
> > behavior has always been a little flaky.
> >
> > Thanks,
> > Kevin
> >
>

iOS: The future of whitelisting

[Kevin Hawkins]

Hey all,

Those of us who have been on the implementing and/or serious consumption
side of whitelisting for iOS—I've been on both at one time or another—know
how much work has gone into trying to make it a full-featured security
subsystem for the iOS version of the framework.  I want to share some
feedback based on my organization's experiences in implementation, and
hopefully spark some discussion about the future of whitelisting on iOS
(and maybe the platform as a whole).

We're essentially running into insurmountable issues with whitelisting for
the use cases we're attempting, based on the overreach of the NSURLProtocol
approach to whitelist handling.  I say overreach because, in an ideal
world, Cordova should only ever care about safeguarding traffic destined to
go through the hybrid/native bridge.  This argument can be made for all
platforms, but the lack of granularity is most onerously overbearing on
iOS, which filters every HTTP(S) packet that goes through the app.

Our requirements are very strict with regard to what's whitelisted to go
through the bridge.  But the bridge is conceptually the only thing we care
about, within that particular sphere of security.  We have a more relaxed
sphere of security for, say, http://maps.google.com"; />, as the
threat vectors exposed through image rendering are considerably less than
malicious injected bridge code.

Alas, we don't—and arguably never will—have that kind of granular control
in iOS, with the current implementation approach.  NSURLProtocol is simply
too broad-brush to meld into a granular approach for whitelisting.  The end
result is that we lose the ability to deliver a rich content experience
that leverages third party artifacts, because we're forced to go with the
sphere of security that gives us the highest scrutiny, across the board.

We've been considering (very early phase) some alternative approaches to
managing whitelisting.  Our current thinking has been focusing on a
gatekeeper (on the native side) to the bridge itself.  This would enforce
some sort of contract between the hybrid and native side, to make a
determination of which traffic is authorized to specifically go through the
bridge.  I'm not sure what that contract looks like at this point, but
enforcement would be bridge-specific, and all other webview traffic would
otherwise behave as it would in a normal web application.

I know from past discussions that many (most?) Cordova developers don't
generally use the whitelist, since their security concerns may not be as
great, and/or they exclusively host their app functionality locally to the
device, which allows them to essentially implement their own controls on
attack vectors through selective app content.  In our case, we're building
an enterprise platform where content could come from any number of sources.
 And whitelisting controls are not working for us.

If there's a future for whitelisting in Cordova 3.0, I personally feel that
it needs to be revisited.  I'd be interested to hear thoughts from others
on their usage patterns, and responses to my concerns.

Cheers,
Kevin

Re: iOS: The future of whitelisting

[Kevin Hawkins]

It's good to hear from all of you. :)  Lots of insightful commentary.
 Shaz, I'm not sure yet how the gatekeeper would work, from that
standpoint.  That's definitely the hard part.  We thought about having a
blanket policy of notifying the user (subject to plugin-specific
configuration) for every plugin call that reaches the native layer, with
the standard "Don't ask again" option included.  But how do you identify
the origin of the call?  Tricky questions all around.

The WebPolicyDelegate approach would be awesome!  I need to figure out who
to blackmail at Apple to get it included in iOS 7. ;-)

Cheers,
Kevin



On Wed, Apr 10, 2013 at 5:29 PM, Shazron  wrote:

> Also the whitelist might be important for plugins. Specifically, people
> that need to install plugins have a promise of what external locations are
> being accessed.
>
> However, right now all iOS plugins bypass the whitelist because of our
> User-Agent method, and that needs to be rectified before this "promise" is
> true.
>
> Certain resources bypass the whitelist anyway because we have no way to
> control them at the moment (audio/video tags):
> https://issues.apache.org/jira/browse/CB-2451
>
>
>
>
> On Wed, Apr 10, 2013 at 5:22 PM, Shazron  wrote:
>
> > Ideally we would have a WebPolicyDelegate like OS X
> > (webView:decidePolicyForMIMEType:):
> >
> >
> https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/WebKit/Protocols/WebPolicyDelegate_Protocol/Reference/Reference.html
> >
> > ...where we can have some granularity - I'm not sure we can yet. If so,
> we
> > can defer to the app developer whether certain things like images can be
> > let through - for example in MainViewController, you can set your own
> > WebPolicyDelegate. We would allow images through by default.
> >
> > I'm not sure of "letting the fox in the hen-house" (allow everything)
> then
> > trying to guard against attacks (hens with shotguns?), this is JavaScript
> > after all. I'm interested however in how your gatekeeper concept works to
> > help with this since allowing an external URL location does not protect
> > from this attach (think of the situation if the external host was hacked,
> > and contained JS that attacks/intercepts our bridge).
> >
> > With the default wildcard in new projects, like others here have
> > mentioned, the whitelist is effectively turned off, and 99% of devs won't
> > care to restrict the whitelist.
> >
> >
> >
> > On Wed, Apr 10, 2013 at 3:06 PM, Braden Shepherdson  >wrote:
> >
> >> Especially since permissions, on platforms that have such a notion, will
> >> be
> >> (eventually...) controlled by installing those plugins. So you can lean
> on
> >> the platform to block access to contacts as well. Even on platforms
> >> without
> >> such permissions control, if we don't load the contacts-retrieval native
> >> code, then the JS can't get at it.
> >>
> >> Braden
> >>
> >>
> >> On Wed, Apr 10, 2013 at 4:44 PM, Jesse  wrote:
> >>
> >> > I am completely in favor of removing whitelisting as well.  I believe
> it
> >> > gives developers a false sense of security.
> >> > imho the only sure way to protect access to the bridge is to only ever
> >> load
> >> > code that you control. We should be pushing developers towards
> >> > best-practices.
> >> >
> >> > Some of the whitelist stuff should become redundant when we have
> things
> >> > like the Contact API moved into plugins.  ie. You can be absolutely
> >> certain
> >> > that no JS code is accessing the device's contacts if you do not
> include
> >> > the native pieces of the Contact API.
> >> >
> >> > @purplecabbage
> >> > risingj.com
> >> >
> >> >
> >> > On Wed, Apr 10, 2013 at 1:23 PM, Brian LeRoux  wrote:
> >> >
> >> > > We recently moved to * by default to ease common userland woe. I'd
> be
> >> in
> >> > > favor of removal of whitelisting but I'm fairly certain that would
> be
> >> > > a controversial position!
> >> > >
> >> > >
> >> > > On Wed, Apr 10, 2013 at 11:38 AM, Kevin Hawkins <
> >> > > kevin.hawkins.cord...@gmail.com> wrote:
> >> > >
> >> > > > Hey all,
> >> > > >
> >> > > > Those of us who have been on the implementing and/or s

Re: iOS: The future of whitelisting

[Kevin Hawkins]

The biggest issue we have with the current whitelisting in iOS, which I do
consider overreaching, is that it applies to every class of request that
comes out of the Cordova web view.  This is most problematic with images.
 I can't include stock service provider icons from e.g. twitter.com or
facebook.com, static map images from google.com, etc., because I can't also
trust those sites to be allowed unfettered access to the bridge.  I.e. I
can't whitelist them, because the definition of their security class is
overly broad, such that I have to apply the rules of a high level of trust
to a low level of risk.  Same would hold true for stylesheets, for example.

It puts us in the unfortunate position of having to choose to either have
apps devoid of the rich content available from third parties, apps that are
at least partially broken between Cordova vs. straight web (broken image
links, etc.), or no Cordova version of the apps at all (because we can't
budge on the pieces that absolutely have to be secured).

Cheers,
Kevin




On Mon, Apr 15, 2013 at 1:52 PM, Shazron  wrote:

> For the overlay thing, at least for iOS if we have a new window option for
> "toolbar=[yes|no]" this would have almost the desired effect, if we take
> out the animation.
>
>
> On Mon, Apr 15, 2013 at 1:44 PM, Andrew Grieve 
> wrote:
>
> > Kevin - the iOS CDVURLProtocol was changed (2.5ish) to only filter
> requests
> > from Cordova WebViews. I'd be interested in hearing if you still think
> it's
> > over-reaching.
> >
> > I think the only real way to protect your app is to not have any
> > third-party scripts in it. We have an outstanding issue to create a guide
> > for this:
> >
> > https://issues.apache.org/jira/browse/CB-2179
> >
> >
> > Would using InAppBrowser suite your need for handling third-party
> content?
> > E.g. What if we made a mode for IAB where it overlays the page (like an
> > iframe) instead of completely covering it?
> >
> >
> >
> >
> > On Thu, Apr 11, 2013 at 2:39 PM, Shravan Narayan  > >wrote:
> >
> > > Hi,
> > > My name is Shravan - I am an intern at Google working on the Cordova
> App
> > > Harness (tool to test Cordova Apps).
> > >
> > > Something that I noticed while starting work on the App Harness. The
> new
> > > executeScript method allows injection of arbitrary pieces of javascript
> > in
> > > the InAppBrowsers opened with "window.open". This script runs in
> context
> > of
> > > the page loaded in the InAppBrowser. Whitelists might be still required
> > in
> > > this scenario.
> > >
> > > *Quick example*
> > > Consider the scenario that there are no whitelists in the platforms.
> Any
> > > cordova app which is vulnerable to XSS attacks, can have the following
> > code
> > > injected into them.
> > >
> > > *w = window.open("www.site_that_your_app_normally_doesnt_access.com",
> > > "_blank");*
> > > *w.executeScript({ file: "some_** malicious**_site.com/malicious.js
> "});
> > > *
> > > *
> > > *
> > > Thus they can open any website and inject any js file from any
> location.
> > > Whereas with whitelists the js file's domain "*some_** malicious**_
> > > site.com"
> > > *  would probably not be a part of the whitelist.
> > >
> > > *Small caveat: *The executeScript does have means to inject code
> directly
> > > as well with *w.executeScript({code:"(function() {alert("Hello");})
> > ();"})
> > > *but
> > > that may require a different solution not pertaining to this
> discussion.
> > >
> > > I don't know if this is a reason to keep the whitelists around but
> > thought
> > > I'd mention it.
> > >
> > > Shravan
> > >
> > >
> > > On Wed, Apr 10, 2013 at 8:29 PM, Shazron  wrote:
> > >
> > > > Also the whitelist might be important for plugins. Specifically,
> people
> > > > that need to install plugins have a promise of what external
> locations
> > > are
> > > > being accessed.
> > > >
> > > > However, right now all iOS plugins bypass the whitelist because of
> our
> > > > User-Agent method, and that needs to be rectified before this
> "promise"
> > > is
> > > > true.
> > > >
> > > > Certain resources bypass the whitelist anyway because we have no way
> to
> > > > co

Re: iOS: The future of whitelisting

[Kevin Hawkins]

Thanks Andrew.  Content filtering may be a way to go, if that's possible.
 Is granular pattern-based whitelisting available in iOS?  I thought it
only went down to the host pattern level.

Cheers,
Kevin



On Mon, Apr 15, 2013 at 4:52 PM, Andrew Grieve  wrote:

> Sounds like CSP (content security policy) will fill your needs, but we'll
> have to wait for webviews to support it.
>
> So, it sounds like this applies to hosted web apps only? E.g., if this was
> a file:// based app, you would want to bundle icons with your app.
>
> Would pattern-based white-list not cover your use-case? e.g.
> gstatic.google.com/*.png
>
> It actually would be feasible to implement content filtering on a mime-type
> basis on iOS & Android 3.0+, but I'm not about to volunteer :P
>
>
>
> On Mon, Apr 15, 2013 at 6:49 PM, Kevin Hawkins <
> kevin.hawkins.cord...@gmail.com> wrote:
>
> > The biggest issue we have with the current whitelisting in iOS, which I
> do
> > consider overreaching, is that it applies to every class of request that
> > comes out of the Cordova web view.  This is most problematic with images.
> >  I can't include stock service provider icons from e.g. twitter.com or
> > facebook.com, static map images from google.com, etc., because I can't
> > also
> > trust those sites to be allowed unfettered access to the bridge.  I.e. I
> > can't whitelist them, because the definition of their security class is
> > overly broad, such that I have to apply the rules of a high level of
> trust
> > to a low level of risk.  Same would hold true for stylesheets, for
> example.
> >
> > It puts us in the unfortunate position of having to choose to either have
> > apps devoid of the rich content available from third parties, apps that
> are
> > at least partially broken between Cordova vs. straight web (broken image
> > links, etc.), or no Cordova version of the apps at all (because we can't
> > budge on the pieces that absolutely have to be secured).
> >
> > Cheers,
> > Kevin
> >
> >
> >
> >
> > On Mon, Apr 15, 2013 at 1:52 PM, Shazron  wrote:
> >
> > > For the overlay thing, at least for iOS if we have a new window option
> > for
> > > "toolbar=[yes|no]" this would have almost the desired effect, if we
> take
> > > out the animation.
> > >
> > >
> > > On Mon, Apr 15, 2013 at 1:44 PM, Andrew Grieve 
> > > wrote:
> > >
> > > > Kevin - the iOS CDVURLProtocol was changed (2.5ish) to only filter
> > > requests
> > > > from Cordova WebViews. I'd be interested in hearing if you still
> think
> > > it's
> > > > over-reaching.
> > > >
> > > > I think the only real way to protect your app is to not have any
> > > > third-party scripts in it. We have an outstanding issue to create a
> > guide
> > > > for this:
> > > >
> > > > https://issues.apache.org/jira/browse/CB-2179
> > > >
> > > >
> > > > Would using InAppBrowser suite your need for handling third-party
> > > content?
> > > > E.g. What if we made a mode for IAB where it overlays the page (like
> an
> > > > iframe) instead of completely covering it?
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, Apr 11, 2013 at 2:39 PM, Shravan Narayan <
> shrava...@google.com
> > > > >wrote:
> > > >
> > > > > Hi,
> > > > > My name is Shravan - I am an intern at Google working on the
> Cordova
> > > App
> > > > > Harness (tool to test Cordova Apps).
> > > > >
> > > > > Something that I noticed while starting work on the App Harness.
> The
> > > new
> > > > > executeScript method allows injection of arbitrary pieces of
> > javascript
> > > > in
> > > > > the InAppBrowsers opened with "window.open". This script runs in
> > > context
> > > > of
> > > > > the page loaded in the InAppBrowser. Whitelists might be still
> > required
> > > > in
> > > > > this scenario.
> > > > >
> > > > > *Quick example*
> > > > > Consider the scenario that there are no whitelists in the
> platforms.
> > > Any
> > > > > cordova app which is vulnerable to XSS attacks, can have the
> > following
> > > > code
> > > > > injected into them.
> > > > 

Re: [iOS] Xcode 6 requirement

[Kevin Hawkins]

Our biggest reason for not having solidly moved to Xcode 6 is that there
are a number of really bad bugs in it.  But Xcode 6.1 seems to have fixed a
lot of those, so I have less reservations about the move now.

Kevin

On Friday, October 17, 2014, Shazron  wrote:

> Yosemite is here. I will add the Xcode 6 requirement.
>
> related: https://github.com/apache/cordova-ios/pull/107
>
> On Tue, Oct 7, 2014 at 12:54 PM, Shazron >
> wrote:
>
> > Alright, I'll hold off on this until Yosemite is released, and will
> update
> > the issue.
> >
> > On Sun, Sep 28, 2014 at 3:30 AM, julio cesar sanchez <
> > jcesarmob...@gmail.com > wrote:
> >
> >> Sorry, I mess up with the OS versions, anyway, my point is any computer
> >> with mountain lion (required by xcode 5) can be updated to maveriks and
> >> yosemite.
> >> Fear to update is other point, I didn't update to maveriks until june (I
> >> wanted to test xcode 6 beta) for the same reasons as you, but I haven't
> >> had
> >> problems so far
> >>
> >> El sábado, 27 de septiembre de 2014, Darryl Pogue  >
> >> escribió:
> >>
> >> > On 27 September 2014 08:48, julio cesar sanchez <
> jcesarmob...@gmail.com 
> >> > > wrote:
> >> > > Any reasons to use xcode 5 and don't update to 6? I think xcode 6
> >> > requires
> >> > > mountain lion or newer, so people with lion and xcode 5 maybe don't
> >> want
> >> > to
> >> > > update the computer from lion to mountain lion or maveriks, but
> >> computers
> >> > > with lion can definitelly update
> >> >
> >> > Xcode 6 requires Mavericks or higher, which means people still on
> >> > Mountain Lion can't
> >> > upgrade.
> >> >
> >> > It would be convenient to keep Xcode 5 support until at least Yosemite
> >> > is released.
> >> > Several devs (myself included) are still on Mountain Lion because of
> >> > Mavericks upgrade
> >> > horror stories, but are planning to install Yosemite when it's
> >> available.
> >> >
> >>
> >
> >
>

RE: Cordova: Comment on Deleting hidekeyboard and showkeyboard Events

[Kevin Nuss]

P.S.LinearLayoutSoftKeyboardDetect.java uses the deprecated method 
“sendJavascript” in CordovaWebView.java. This ends up causing violations of 
Content-Security-Policy rules since I am using fairly strict ones that do not 
include ‘unsafe-eval’ . But events from backbutton and online/offline network 
status do not cause violations. I have not tested other plugins.

Kevin Nuss


From: mmo...@google.com [mailto:mmo...@google.com] On Behalf Of Michal Mocny
Sent: Wednesday, November 05, 2014 10:50
To: dev
Cc: Andrew Grieve; Kevin Nuss
Subject: Re: Cordova: Comment on Deleting hidekeyboard and showkeyboard Events

Telling people to turn to [insert any project from the external community] for 
[a feature we used to support but is now openly supported elsewhere] -- sounds 
amazing to me.

What happened to the goal of "eventually cease to exist"?

On Wed, Nov 5, 2014 at 11:26 AM, Joe Bowser 
mailto:bows...@gmail.com>> wrote:
On Wed Nov 05 2014 at 8:21:03 AM Andrew Grieve 
mailto:agri...@chromium.org>> wrote:

> Here's the ionic plugin:
> https://github.com/driftyco/ionic-plugins-keyboard/blob/master/src/android/IonicKeyboard.java
>
> Uses a GlobalLayoutListener. the approach is described here:
> http://stackoverflow.com/questions/2150078/how-to-check-visibility-of-software-keyboard-in-android
>
> Why leave the code in core if we don't have to? I think the majority of
> apps wouldn't need these events (even if you do, you can listen for resize
> events to do the same kind of detection)
>

I think this will break more things than it'll fix.  Does the Ionic plugin
support all the versions of Android that we currently support? Are we
really going to tell people to go to Ionic for a feature that we once
supported? Even if this is technically better, this seems like it's a
support nightmare.


>
> On Wed, Nov 5, 2014 at 11:05 AM, Joe Bowser 
> mailto:bows...@gmail.com>> wrote:
>
>> I disagree. We recently fixed this when we went back to adjustResize from
>> adjustPan, and we should just file a bug about the behaviour on the Samsung
>> Tablet.
>>
>
>

iOS: CDVViewController.startPage - Any thoughts/plans on allowing full URLs there?

[Kevin Hawkins]

We're building out frameworks based on Cordova that have feature parity between 
Android and iOS.  We've come into a refactoring project in our frameworks where 
it would be very useful to be able to optionally jump straight from native to 
an HTTP(S) endpoint as our start page.  Android can do this, but this 
functionality is not available in the iOS offering.

My question is, is this deliberately missing, or just something that never 
really got into the update queue?  I'd be willing to take a look at it, but it 
seemed prudent to first ask if there are good reasons for that not being 
available in iOS.

Cheers,
Kevin

Re: iOS: CDVViewController.startPage - Any thoughts/plans on allowing full URLs there?

[Kevin Hawkins]

Thanks Andrew.  I'll start poking around with it, and see how it goes.  Shaz 
will probably have thoughts too. :)

Cheers,
Kevin


On Oct 24, 2012, at 7:21 PM, "Andrew Grieve"  wrote:

> It's probably something that's just not been gotten to yet. Going straight
> to the web means your app won't work offline out-of-the-box though, and
> might hurt your appstore approval chances.
> 
> It'd be worth adding to Cordova anyways though, as it's useful for testing,
> and as you pointed out, Android supports it.
> There's also another related bug here:
> https://issues.apache.org/jira/browse/CB-1475
> 
> 
> On Wed, Oct 24, 2012 at 10:06 PM, Kevin Hawkins 
> wrote:
> 
>> We're building out frameworks based on Cordova that have feature parity
>> between Android and iOS.  We've come into a refactoring project in our
>> frameworks where it would be very useful to be able to optionally jump
>> straight from native to an HTTP(S) endpoint as our start page.  Android can
>> do this, but this functionality is not available in the iOS offering.
>> 
>> My question is, is this deliberately missing, or just something that never
>> really got into the update queue?  I'd be willing to take a look at it, but
>> it seemed prudent to first ask if there are good reasons for that not being
>> available in iOS.
>> 
>> Cheers,
>> Kevin
>> 
>> 

iOS: Why does the cordova.js filename change?

[Kevin Hawkins]

Hi all,

Apologies if/that I've missed this discussion previously.  I'm not clear on why 
the cordova.js file name changes in the iOS repo, particularly given the fact 
that great lengths seem to have been taken everywhere to be agnostic about what 
the originating name is, opting to dynamically update the destination name in 
build scripts, template generation, etc.?

Changing the originating file name with each new iteration/revision of Cordova 
makes it hard to follow its history on GitHub (though it's easy enough locally 
with git log and --follow), and just generally seems unnecessary.

Thanks,
Kevin

So long...from this address

[Kevin Hawkins]

Not that anyone notices down to the originating email address details, but I'm 
going to bail on the list from this (work) email account, since it seems to be 
overly aggressive in rejecting random emails to/from the list.  I'm moved over 
to a Gmail account, which I assume will be much more permissive.

That is all.  Carry on. :)

Cheers,
Kevin

Re: Whitelist defaults

[Kevin Hawkins]

>From a security perspective, I'm partial to the iOS (nothing) default,
recognizing of course that there are certain usability drawbacks to that
approach.

On Thu, Nov 1, 2012 at 4:34 PM, Filip Maj  wrote:

> Quick q: how come Android + BB's whitelists by default whitelist
> everything (*), but iOS does the opposite (whitelist nothing)?
>
> I'd like to see this unified across all platforms we support.
>
>

Re: iOS: Why does the cordova.js filename change?

[Kevin Hawkins]

+1 to one copy.  And preferably, one name (e.g. cordova.ios.js or similar)
for the originating file.  As mentioned, the various deployment scripts
(e.g. Makefile) recreate the destination file name anyway, based on the
contents of the VERSION file.  And that to me seems like a pretty good
model to follow.

I generally agree with Shaz: cordova.js is pretty tightly coupled with
CordovaLib updates/versioning, so it probably makes sense to be a resource
somewhere in that path.

My $0.02,
Kevin


On Fri, Nov 2, 2012 at 2:49 PM, Andrew Grieve  wrote:

> It actually does bother me a little bit too, to have the file name have a
> version in it when we're developing.
>
> I don't really care where we put the file so long as there is only one copy
> of it and not multiple.
>
>
> On Wed, Oct 31, 2012 at 4:22 PM, Shazron  wrote:
>
> > On iOS, the cordova.js used to (inertia really because of the legacy
> > location) be in the CordovaLib folder, and also the template. Since it
> > was redundant, we only put it in the default template in
> > bin/templates/project now.
> >
> > Even this is not ideal with respect to people upgrading and using it
> > as an embedded WebView -- to grab the new .js they have to create a
> > new project (or spelunk into the bin/templates folder). Ideally it
> > should be put back also into CordovaLib because the .js is tightly
> > coupled to a specific CordovaLib library and version, and for easy
> > discovery. Don't know what the ideal situation can be here.
> >
> > On Tue, Oct 30, 2012 at 5:34 PM, Kevin Hawkins 
> > wrote:
> > > Hi all,
> > >
> > > Apologies if/that I've missed this discussion previously.  I'm not
> clear
> > on why the cordova.js file name changes in the iOS repo, particularly
> given
> > the fact that great lengths seem to have been taken everywhere to be
> > agnostic about what the originating name is, opting to dynamically update
> > the destination name in build scripts, template generation, etc.?
> > >
> > > Changing the originating file name with each new iteration/revision of
> > Cordova makes it hard to follow its history on GitHub (though it's easy
> > enough locally with git log and --follow), and just generally seems
> > unnecessary.
> > >
> > > Thanks,
> > > Kevin
> > >
> >
>

Re: Whitelist defaults

[Kevin Hawkins]

In our customizations of our Cordova app, that's exactly what we did.  We
created a Cordova-Debug.plist and Cordova-Release.plist, and synced them
back to Cordova.plist as a Build Phase step.  I don't know that it's the
default behavior the Cordova community would want for template apps, but it
is doable anyway.

On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI  wrote:

> I guess the consensus is to whitelist everything (*) all the time.
>
> My opinion is that there should be some dev mode where (*) is set and then
> a release mode where you'd specify your hosts.
>
>
> On Mon, Nov 5, 2012 at 3:11 PM, Shazron  wrote:
>
> > We've had the discussion. So what is the decision/consensus? Leave as is,
> > or add "*" to default settings for all, with a warning in the console
> log?
> >
> >
> >
> > On Fri, Nov 2, 2012 at 11:33 AM, Joe Bowser  wrote:
> >
> > > On Fri, Nov 2, 2012 at 10:59 AM, Shazron  wrote:
> > > > Echoing Anis here. The easiest use case is for corporate use
> > (internal),
> > > > where any connections are restricted to a certain domain for paranoid
> > IT
> > > > types.
> > > >
> > > > I can see the case of us allowing everything _by default_ though (eg
> > > adding
> > > > the '*'), which really should have been the default so as to be
> > > "backwards
> > > > compatible" with how it was before the whitelist came in. The system
> > > could
> > > > detect this sole wildcard entry, and print out a warning in the
> console
> > > > log, as well as the documentation of course pointing this out -- the
> > > latter
> > > > which we should have done in the first place.
> > >
> > > OK, that sounds cool, but does that mean that in six months, we're
> > > going to deprecate this behaviour and get more aggressive with the
> > > whitelist?
> > >
> > > BTW: In the event that the whitelist isn't found based on the code
> > > that I'm looking at here, Android should block everything and fire
> > > default web intents.  If it's not doing this, that's a bug! When we
> > > refer to defaults, are we referring to the config.xml that we're
> > > circulating?
> > >
> > > Also, how are we testing this whitelisting feature? I can tell you
> > > that doing it in JS alone wouldn't be enough.
> > >
> > > Joe
> > >
> >
>

Re: Whitelist defaults

[Kevin Hawkins]

Yeah, it's something we take care with in our implementation. Primarily, we
use the separation to include things wholesale in Debug that we don't want
in Release, such as TestFlight, and other performance gathering code that
is disabled in release builds.

On Tuesday, November 6, 2012, Andrew Grieve wrote:

> Adding * by default SGTM. Having separate debug/release whitelists sounds
> dangerous though. You don't want your app to work in debug mode and then be
> broken when you release it.
>
>
> On Mon, Nov 5, 2012 at 7:26 PM, Anis KADRI  wrote:
>
> > I confirm that Android also uses config.xml.
> >
> >
> > On Mon, Nov 5, 2012 at 4:22 PM, Shazron  wrote:
> >
> > > I would think all unsupported devices for the whitelist feature remain
> > > unsupported (and is documented as such:
> > >
> > >
> >
> http://docs.phonegap.com/en/2.2.0/guide_whitelist_index.md.html#Domain%20Whitelist%20Guide
> > > )
> > >
> > >
> > > On Mon, Nov 5, 2012 at 4:14 PM, Jesse  wrote:
> > >
> > > > Does this mean that whitelists should be added to Bada, Symbian,
> > > > WebOS, Windows Phone, and Windows 8?
> > > >
> > > > Also, while we are discussing it, wouldn't it be good to have all
> > > > platforms have a consistent way of defining access-permissions ?
> > > >
> > > > Android:: res/xml/cordova.xml
> > > > Blackberry:: www/config.xml
> > > > iOS:: Cordova.plist
> > > > Tizen:: config.xml
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Nov 5, 2012 at 3:58 PM, Shazron  wrote:
> > > > > What Anis said last is what I meant. Since BB and Android have this
> > > > > behaviour already this doesn't impact those platforms as much. Will
> > > wait
> > > > > for comments until tomorrow then I will add some JIRA task(s).
> > > > >
> > > > >
> > > > > On Mon, Nov 5, 2012 at 3:43 PM, Anis KADRI 
> > > wrote:
> > > > >
> > > > >> On Mon, Nov 5, 2012 at 3:36 PM, Brian LeRoux  wrote:
> > > > >>
> > > > >> > Why would we require a new property? We're just talking about
> > adding
> > > > * as
> > > > >> > the default property.
> > > > >> >
> > > > >>
> > > > >> I believe this applied only if we did a debug/release mode
> strategy.
> > > > Adding
> > > > >> (*) as default doesn't require a new property from what I
> > understand.
> > > > >>
> > > > >>
> > > > >> >
> > > > >> > (Also, Jesse, I have talked to many Cordova devs whom have
> > expressed
> > > > >> > frustration with our default.)
> > > > >> >
> > > > >> > I feel we have consensus enough to document and add this
> default.
> > > > >> >
> > > > >> >
> > > > >> > On Mon, Nov 5, 2012 at 3:26 PM, Shazron 
> > wrote:
> > > > >> >
> > > > >> > > Well it's all or nothing. There is no "dev" mode with respect
> to
> > > the
> > > > >> > plist
> > > > >> > > itself as it is right now, unless we want to add yet another
> > plist
> > > > >> > > property.
> > > > >> > >
> > > > >> > >
> > > > >> > > On Mon, Nov 5, 2012 at 3:22 PM, Anis KADRI <
> > anis.ka...@gmail.com>
> > > > >> wrote:
> > > > >> > >
> > > > >> > > > I guess the consensus is to whitelist everything (*) all the
> > > time.
> > > > >> > > >
> > > > >> > > > My opinion is that there should be some dev mode where (*)
> is
> > > set
> > > > and
> > > > >> > > then
> > > > >> > > > a release mode where you'd specify your hosts.
> > > > >> > > >
> > >

Re: iOS 4.3 support, do we need it?

[Kevin Hawkins]

If this 
metricis
to be believed, 4.3.x installs account for well under 10% of all iOS
installs at this point.  Seems like 5.0 would be a safe bet, at least to me.


On Tue, Nov 6, 2012 at 1:16 PM, Anis KADRI  wrote:

> +1 for 5.0 and above. Even my 3rd generation iPod touch has iOS 5.0.
>
>
> On Tue, Nov 6, 2012 at 12:46 PM, Shazron  wrote:
>
> > So, iOS 6 supports as a minimum iOS 4.3 devices (armv7 and up, no more
> > armv6).
> >
> > I am loathe to put out a release without testing it on iOS 4.3, but I
> have
> > no choice since I can't find a device that has iOS 4.3 on it. I could
> find
> > and hack in the iOS 4.3 Simulator, but there are some device features
> that
> > don't work on that of course (like the accelerometer, compass, etc).
> >
> > You can't downgrade a device to 4.3 unless you have the shsh blobs for
> 4.3
> > for your device. Most people won't have that unless they jailbroke their
> > device while on 4.3. Trying it through iTunes legitimately with 4.3
> > firmware is "not allowed" by Apple's servers, they will point you to the
> > latest firmware for your device, which would be iOS 6.0 for the devices
> we
> > support.
> >
> > So -- would requiring iOS 5.0 minimum for Cordova be unreasonable here? I
> > can put out feelers on the PhoneGap mailing list to see what other
> Cordova
> > devs think as well.
> >
>

Re: iOS: Can we clean up the view lifecycle in 2.3?

[Kevin Hawkins]

Sorry, I realize after the fact that my email wasn't particularly helpful,
without specifics.  So here's an outline of my initial audit of the
view/view controller/app delegate code.  For the record, I'm working
against HEAD of the repo, as far as what version of Cordova I'm considering.


   1. App template's AppDelegate: the forceStartupLocation
   logic in application:didFinishLaunchingWithOptions: is not necessary.  An
   iOS app will default to a supported orientation at startup, if the current
   orientation is not supported.

   2. CDVCordovaView inherits from UIWebView.  Apple's documentation
   explicitly says not to inherit from UIWebView.

   3. [CDVViewController __init] sets its wantsFullScreenLayout property to
   YES.  This explicitly tells the view controller to ignore the layout of the
   status bar.  This one took hours to track down. :(  This should not be the
   default behavior of a Cordova app, and is the stemming point for all of the
   issues around having to manually deal with the position/spacing of the
   status bar, specifically around having to set an explicit view frame for
   the main view. The explicit frame setting, in turn, was affecting view
   layout when using (and specifically, dismissing) modal view controllers.

   After turning this off (or I should say removing the assignment; default
   iOS behavior has this property set to NO), it becomes no longer necessary
   to explicitly set self.view.frame anywhere; [MainViewController
   viewWillAppear:] can go away entirely.

The list is shorter than I thought, which is good. :)  I think I had blown
it up in my mind a bit, with the amount of trouble I was having with the
status bar and view frame, relative to the complete lack of trouble I was
having with it in other iOS apps.

I didn't get too much into the splash screen stuff.  As implemented, I can
see that the property should be set to NO in the event that Cordova is
being used as a component, as it sets subviews outside of the Cordova view
hierarchy.  Seems reasonable, though.  Also, in [CDVViewController
showSplashScreen], the self.imageView.autoresizingMask setting is probably
not what it's supposed to be; those values should be bitwise-ORed together,
not bitwise-ANDed.  The net effect at the moment is going to be that the
autoresizing mask has a value of UIViewAutoresizingNone.

That's all for now. :)

Cheers,
Kevin



On Tue, Nov 6, 2012 at 12:39 PM, Shazron  wrote:

> I can create a native application in iOS today using Apple's most basic
>
> > template, create a UIViewController subclass from there, programmatically
> > manage my UIView and UIWebView, get full rotation and status bar
> > management, and all of this with literally half a dozen lines of custom
> > code or less.  There's no fussing with autorotation, outside of initial
> > configuration of supported modes.  There's no managing the status bar
> when
> > determining the frame.  There's no setting of the default view's frame at
> > all, in fact: it defaults to the size of its superview (the UIWindow in
> > this case), and automatically adjusts to the status bar.  The status bar
> > rotation is self-managed too.
> >
>
> I don't see these problems you are seeing. Are you using 2.2.0? There is no
> setting of the frame, it uses the screen bounds (see
> AppDelegate.m). Autorotation is managed as well. The default template
> dog-foods using Cordova as an embedded WebView as specified in the docs -
> although the doc is outdated where it has to set the frame, the template
> uses it differently in AppDelegate.m. We will have to update the doc.
>
>
> > Conversely, all of these things are custom-managed and complicated in the
> > CDVViewController and its related counterparts.  And they don't play by
> the
> > rules of standard iOS behavior.  You have to employ weird, wonky code to
> > adjust  the view to be under the status bar...conditionally.
>  Autorotation
> > doesn't work if you present a view controller; you have to use wonky code
> > to reset the parent view controller in its viewWillAppear as well, once
> the
> > modal vc has been dismissed.
> >
>
> I've never seen that problem anymore though in 2.2.0 (statusbar over the
> view) - only saw that with one of your pull requests that got fixed with
> some other code (to be honest I don't know what was going on there). That
> problem (reset parent viewcontroller) is fixed with this bug fix in 2.2.0
> https://issues.apache.org/jira/browse/CB-1465 -- the viewcontroller size
> is
> only set once in that case.
>
> I don't know if the required manual management of these things is a legacy
> > of older versions of iOS.  But I know that that requirement is older than
> > o

Re: iOS: Can we clean up the view lifecycle in 2.3?

[Kevin Hawkins]

I'll add the corresponding JIRA tasks, and put some pull requests together.
 Not a lot of code changes involved.

Thanks,
Kevin


On Thu, Nov 8, 2012 at 12:50 PM, Shazron  wrote:

> Thanks Kevin, this is great :) Once I have time I can put these into JIRA
> tasks or if you are inclined to file them as well, that will be great.
>
>
> On Thu, Nov 8, 2012 at 11:47 AM, Kevin Hawkins <
> kevin.hawkins.cord...@gmail.com> wrote:
>
> > Sorry, I realize after the fact that my email wasn't particularly
> helpful,
> > without specifics.  So here's an outline of my initial audit of the
> > view/view controller/app delegate code.  For the record, I'm working
> > against HEAD of the repo, as far as what version of Cordova I'm
> > considering.
> >
> >
> >1. App template's AppDelegate: the forceStartupLocation
> >logic in application:didFinishLaunchingWithOptions: is not necessary.
> >  An
> >iOS app will default to a supported orientation at startup, if the
> > current
> >orientation is not supported.
> >
> >2. CDVCordovaView inherits from UIWebView.  Apple's documentation
> >explicitly says not to inherit from UIWebView.
> >
> >3. [CDVViewController __init] sets its wantsFullScreenLayout property
> to
> >YES.  This explicitly tells the view controller to ignore the layout
> of
> > the
> >status bar.  This one took hours to track down. :(  This should not be
> > the
> >default behavior of a Cordova app, and is the stemming point for all
> of
> > the
> >issues around having to manually deal with the position/spacing of the
> >status bar, specifically around having to set an explicit view frame
> for
> >the main view. The explicit frame setting, in turn, was affecting view
> >layout when using (and specifically, dismissing) modal view
> controllers.
> >
> >After turning this off (or I should say removing the assignment;
> default
> >iOS behavior has this property set to NO), it becomes no longer
> > necessary
> >to explicitly set self.view.frame anywhere; [MainViewController
> >viewWillAppear:] can go away entirely.
> >
> > The list is shorter than I thought, which is good. :)  I think I had
> blown
> > it up in my mind a bit, with the amount of trouble I was having with the
> > status bar and view frame, relative to the complete lack of trouble I was
> > having with it in other iOS apps.
> >
> > I didn't get too much into the splash screen stuff.  As implemented, I
> can
> > see that the property should be set to NO in the event that Cordova is
> > being used as a component, as it sets subviews outside of the Cordova
> view
> > hierarchy.  Seems reasonable, though.  Also, in [CDVViewController
> > showSplashScreen], the self.imageView.autoresizingMask setting is
> probably
> > not what it's supposed to be; those values should be bitwise-ORed
> together,
> > not bitwise-ANDed.  The net effect at the moment is going to be that the
> > autoresizing mask has a value of UIViewAutoresizingNone.
> >
> > That's all for now. :)
> >
> > Cheers,
> > Kevin
> >
> >
> >
> > On Tue, Nov 6, 2012 at 12:39 PM, Shazron  wrote:
> >
> > > I can create a native application in iOS today using Apple's most basic
> > >
> > > > template, create a UIViewController subclass from there,
> > programmatically
> > > > manage my UIView and UIWebView, get full rotation and status bar
> > > > management, and all of this with literally half a dozen lines of
> custom
> > > > code or less.  There's no fussing with autorotation, outside of
> initial
> > > > configuration of supported modes.  There's no managing the status bar
> > > when
> > > > determining the frame.  There's no setting of the default view's
> frame
> > at
> > > > all, in fact: it defaults to the size of its superview (the UIWindow
> in
> > > > this case), and automatically adjusts to the status bar.  The status
> > bar
> > > > rotation is self-managed too.
> > > >
> > >
> > > I don't see these problems you are seeing. Are you using 2.2.0? There
> is
> > no
> > > setting of the frame, it uses the screen bounds (see
> > > AppDelegate.m). Autorotation is managed as well. The default template
> > > dog-foods using Cordova as an embedded WebView as specified in the
> docs -
> > > although the doc is outdat

Cordova http request

[Kevin Palmer]

I am working on an android TV project with the android emulator.

Im really at a loss here.  I simply cannot get a http request to work with 
cordova on the android tv emulator.

I tried all the recommendations on your website.  Ive also scoured the internet 
and adjusted the whitelisting of the config.xml  and the index.html with the 
meta tag in the project folder. I always get this error no matter what I do.

I verified the url and everything.  Ive tried the regular XMLHttp request, and 
$.ajax with every possibility.  Ive tried everything on Android side.  Updating 
the SDK, the sdks tools, the plugin etc.

Can you help?  Please and thank you.  Kevin.  The url is www.ucg.org/api/v1.0

[GitHub] cordova-android pull request #379: CB-12802: (android) When multiple APKs bu...

[kevin-lot]

GitHub user kevin-lot opened a pull request:

https://github.com/apache/cordova-android/pull/379

CB-12802: (android) When multiple APKs build is enable, you cannot sign and 
the build crashes.

When 'cdvBuildMultipleApks' is true, 'task.name' can have 
'validateSigningArmv7Release' or 'validateSigningX86Release' values.

### Platforms affected
cordova 7
cordova-android 6.2.3

### What does this PR do?
Fix build.gradle to sign when multiple APK is enable.

### What testing has been done on this change?
Test to build with or without signature and with or without multiple APK.

### Checklist
- [x] [Reported an issue](http://cordova.apache.org/contribute/issues.html) 
in the JIRA database
- [] Commit message follows the format: "CB-3232: (android) Fix bug with 
resolving file paths", where CB- is the JIRA ID & "android" is the platform 
affected.
- [ ] Added automated test coverage as appropriate for this change.


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Keyclic/cordova-android 6.2.x

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/cordova-android/pull/379.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #379
    
----
commit b57ee1afa10b4cfba8858742d43404fab536d0e0
Author: Kevin Lot 
Date:   2017-05-11T17:58:29Z

Include missing values for task.name

When 'cdvBuildMultipleApks' is true, 'task.name' can have 
'validateSigningArmv7Release' or 'validateSigningX86Release' values.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org
For additional commands, e-mail: dev-h...@cordova.apache.org

iOS: Cordova framework target

[Kevin Hawkins]

I've been long out of the day-to-day happenings of the Cordova project, so
I apologize if this ground has been covered before; I searched back through
my archive and didn't immediately see anything related.  I'll see if I can
keep this description as concise as possible.

For our iOS SDK, we ship a dynamic framework that depends on Cordova.  We
have consumers who depend on both our framework and directly upon Cordova.
They would like to be able to manage their Cordova dependency themselves.
The cleanest way to do this would be if we could both build a
"Cordova.framework" out of the CordovaLib project, and manage the Cordova
dependency itself as a dynamic framework.

I know this isn't the way most people consume Cordova—the approach is more
of a traditional native iOS app with hybrid dependencies.  But it also
doesn't seem like a huge stretch to provide the additional target in the
CordovaLib project.  It's something we could probably take a look at
contributing, but I wanted to float the idea to the list first, to get a
sense of any reservations.

Thanks!
Kevin

Re: iOS: Cordova framework target

[Kevin Hawkins]

I guess CB-12050 <https://issues.apache.org/jira/browse/CB-12050> would be
related, as far as that goes.

On Tue, Jan 17, 2017 at 3:13 PM, Kevin Hawkins <
kevin.hawkins.cord...@gmail.com> wrote:

> I've been long out of the day-to-day happenings of the Cordova project, so
> I apologize if this ground has been covered before; I searched back through
> my archive and didn't immediately see anything related.  I'll see if I can
> keep this description as concise as possible.
>
> For our iOS SDK, we ship a dynamic framework that depends on Cordova.  We
> have consumers who depend on both our framework and directly upon Cordova.
> They would like to be able to manage their Cordova dependency themselves.
> The cleanest way to do this would be if we could both build a
> "Cordova.framework" out of the CordovaLib project, and manage the Cordova
> dependency itself as a dynamic framework.
>
> I know this isn't the way most people consume Cordova—the approach is more
> of a traditional native iOS app with hybrid dependencies.  But it also
> doesn't seem like a huge stretch to provide the additional target in the
> CordovaLib project.  It's something we could probably take a look at
> contributing, but I wanted to float the idea to the list first, to get a
> sense of any reservations.
>
> Thanks!
> Kevin
>
>

[jira] [Commented] (CB-1830) iOS: CDVViewController's wantsFullScreenLayout property should not be set

[Kevin Hawkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-1830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13494378#comment-13494378
 ] 

Kevin Hawkins commented on CB-1830:
---

Pull request at https://github.com/apache/incubator-cordova-ios/pull/64.

> iOS: CDVViewController's wantsFullScreenLayout property should not be set
> -
>
> Key: CB-1830
> URL: https://issues.apache.org/jira/browse/CB-1830
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: Master
>Reporter: Kevin Hawkins
>Assignee: Shazron Abdullah
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In [CDVViewController __init], CDVViewController.wantsFullScreenLayout is set 
> to YES.  The effect of this property is to ignore the status bar layout, for 
> apps that want their views to take space underneath a (presumably 
> translucent) status bar.
> This should not be the default behavior for a Cordova app, and causes a lot 
> of additional configuration of CDVViewController's main view, which otherwise 
> would not be necessary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1831) iOS: App template should not manually configure forced rotation

[Kevin Hawkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13494405#comment-13494405
 ] 

Kevin Hawkins commented on CB-1831:
---

Pull request at https://github.com/apache/incubator-cordova-ios/pull/65.

> iOS: App template should not manually configure forced rotation
> ---
>
> Key: CB-1831
> URL: https://issues.apache.org/jira/browse/CB-1831
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: iOS
>Affects Versions: Master
>Reporter: Kevin Hawkins
>Assignee: Shazron Abdullah
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> There's a considerable block of code in the app template's AppDelegate for 
> trying to control the startup rotation of the app, and force it to a 
> supported rotation if the rotation of the device is not supported in the app.
> This code is unnecessary; an iOS app will manage this behavior automatically. 
>  As such, this code can be removed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1832) iOS: CDVCordovaView should not inherit from UIWebView

[Kevin Hawkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13494414#comment-13494414
 ] 

Kevin Hawkins commented on CB-1832:
---

This one probably requires some discussion.  Functionally, we could just change 
the webView to be a UIWebView, and take away CDVCordovaView.  However, 
CDVCordovaView is "out there", and we can't guarantee that removing it wouldn't 
break compatibility with existing apps, if developers have in turn extended 
that class in their apps.  Thoughts?

> iOS: CDVCordovaView should not inherit from UIWebView
> -
>
> Key: CB-1832
> URL: https://issues.apache.org/jira/browse/CB-1832
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: iOS
>    Affects Versions: Master
>Reporter: Kevin Hawkins
>Assignee: Shazron Abdullah
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> CDVCordovaView inherits from UIWebView.  Apple's documentation for UIWebView 
> states that classes should not inherit from this class.  Most straightforward 
> recommendation is to simply remove CDVCordovaView, and make 
> CDVViewController's webView property actually be a UIWebView.  There's 
> currently no custom logic in CDVCordovaView to support a custom view anyway.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1832) iOS: CDVCordovaView should not inherit from UIWebView

[Kevin Hawkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13494426#comment-13494426
 ] 

Kevin Hawkins commented on CB-1832:
---

Looking back through the repo history, I see that this view has existed more or 
less in its current incarnation for a very long time, back into the PhoneGap 
days.  Given that the world hasn't exploded as a result, this probably isn't a 
high priority

> iOS: CDVCordovaView should not inherit from UIWebView
> -
>
> Key: CB-1832
> URL: https://issues.apache.org/jira/browse/CB-1832
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: iOS
>Affects Versions: Master
>Reporter: Kevin Hawkins
>Assignee: Shazron Abdullah
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> CDVCordovaView inherits from UIWebView.  Apple's documentation for UIWebView 
> states that classes should not inherit from this class.  Most straightforward 
> recommendation is to simply remove CDVCordovaView, and make 
> CDVViewController's webView property actually be a UIWebView.  There's 
> currently no custom logic in CDVCordovaView to support a custom view anyway.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1833) iOS: Splash screen imageView's autoresizingMask is not configured properly

[Kevin Hawkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-1833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13494446#comment-13494446
 ] 

Kevin Hawkins commented on CB-1833:
---

Pull request at https://github.com/apache/incubator-cordova-ios/pull/66.

> iOS: Splash screen imageView's autoresizingMask is not configured properly
> --
>
> Key: CB-1833
> URL: https://issues.apache.org/jira/browse/CB-1833
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: Master
>Reporter: Kevin Hawkins
>Assignee: Shazron Abdullah
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> In [CDVViewController showSplashScreen], the imageView property's 
> autoresizingMask is comprised of UIViewAutoresizing values that are 
> bitwise-ANDed together.  These should be bitwise-ORed together.  The net 
> effect is that the view inadvertently does not support autoresizing: its 
> resultant value will always be 0 (UIViewAutoresizingNone).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CB-1946) iOS: Switch JSON serialization to NSJSONSerialization

[Kevin Hawkins (JIRA)]

Kevin Hawkins created CB-1946:
-

 Summary: iOS: Switch JSON serialization to NSJSONSerialization
 Key: CB-1946
 URL: https://issues.apache.org/jira/browse/CB-1946
 Project: Apache Cordova
  Issue Type: Task
  Components: iOS
Affects Versions: 2.3.0
Reporter: Kevin Hawkins
Assignee: Shazron Abdullah


Now that iOS 5.0 is a baseline requirement for Cordova for iOS, it would be 
good to move away from the JSONKit dependency, in favor of Cocoa's built-in 
NSJSONSerialization, which was added in iOS 5.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CB-2059) [iOS] CDVPlugin's viewController property should be CDVViewController

[Kevin Hawkins (JIRA)]

Kevin Hawkins created CB-2059:
-

 Summary: [iOS] CDVPlugin's viewController property should be 
CDVViewController
 Key: CB-2059
 URL: https://issues.apache.org/jira/browse/CB-2059
 Project: Apache Cordova
  Issue Type: Improvement
  Components: iOS
Affects Versions: 2.3.0
Reporter: Kevin Hawkins
Assignee: Shazron Abdullah
Priority: Minor


CDVPlugin exposes a viewController property, which is currently of the type 
UIViewController.  Seems like it should be an instance of CDVViewController, 
unless there are scenarios where Cordova plugins would be instantiated from a 
non-Cordova view controller.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1465) WebView too small after closing of a ChildBrowser in landscape orientation

[Kevin Hawkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-1465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534140#comment-13534140
 ] 

Kevin Hawkins commented on CB-1465:
---

The Cordova repos moved since then.  You should be able to get the same patch 
now at 
https://git-wip-us.apache.org/repos/asf?p=cordova-ios.git;a=commit;h=681016b3.  
Or the following github.com link 
(https://github.com/apache/cordova-ios/commit/681016b3e0e7e006657406fc0158aaa8515c3369)
 will work too.

> WebView too small after closing of a ChildBrowser in landscape orientation
> --
>
> Key: CB-1465
> URL: https://issues.apache.org/jira/browse/CB-1465
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Affects Versions: 2.1.0
> Environment: iOS devices or simulators with iOS 5 or 6
>Reporter: Jochen Magnus
>Assignee: Shazron Abdullah
>  Labels: ChildBrowser, Orientation
> Fix For: 2.2.0
>
> Attachments: index.html, screenshot-1.jpg
>
>
> After closing the Childbrowser view in landscape orientation, the main 
> webView remains too small. The width seems to be the device with in portrait 
> orientation.
> The problem occurs since Cordova version 2.1.0.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1475) Allow Cleaver to use as a wwwFolderName an absolute path (eg. ~/Library)

[Kevin Hawkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13483893#comment-13483893
 ] 

Kevin Hawkins commented on CB-1475:
---

I would second the desire to be able to specify an absolute path for the 
startPage, from a different angle: mimicking Android Cordova's behavior, I 
would like iOS to be able to specify an absolute web (HTTP(S)) path for the 
start page as well.

We could kill two birds with one stone in this issue, if we added an additional 
(BOOL) property specifying whether startPage represented an absolute path or 
not.

> Allow Cleaver to use as a wwwFolderName an absolute path (eg. ~/Library)
> 
>
> Key: CB-1475
> URL: https://issues.apache.org/jira/browse/CB-1475
> Project: Apache Cordova
>  Issue Type: Improvement
>  Components: iOS
>Affects Versions: 2.0.0
>Reporter: Paris Stamatopoulos
>Assignee: Shazron Abdullah
>Priority: Minor
> Fix For: 2.3.0
>
>
> Currently - (NSString*) pathForResource:(NSString*)resourcepath returns the 
> path based on the current [NSBundle]. However one might be interested in 
> loading the application from an absolute path (e.g. user's ~/Library). 
> Take this snippet for instance:
> NSString *libraryPath = 
> [NSSearchPathForDirectoriesInDomains(NSLibraryDirectory,NSUserDomainMask, 
> YES) lastObject];
> NSString *folderPath   = [libraryPath stringByAppendingPathComponent:@"www"];
> 
> cdvViewController.wwwFolderName = folderPath;

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CB-1755) iOS: Allow customization of whitelist rejection message

[Kevin Hawkins (JIRA)]

Kevin Hawkins created CB-1755:
-

 Summary: iOS: Allow customization of whitelist rejection message
 Key: CB-1755
 URL: https://issues.apache.org/jira/browse/CB-1755
 Project: Apache Cordova
  Issue Type: Improvement
  Components: iOS
Affects Versions: 2.2.0
Reporter: Kevin Hawkins
Assignee: Shazron Abdullah


[CDVWhitelist errorStringForURL:] currently returns the hard-coded error 
string, "ERROR whitelist rejection: url='[failed URL]'", used when a host fails 
its whitelist check.  It would be nice if the format string for this message 
could be user-defined/customized.  A couple of suggested solutions:

- Access a customized message internally in errorStringForURL, by having a 
well-defined localization key to reference it, and defaulting to the original 
value if it hasn't been set.
- Add a public property on CDVWhitelist to specify it, same "default" behavior 
as above.

The latter is probably the most flexible.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1506) Implement InAppBrowser feature

[Kevin Hawkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491676#comment-13491676
 ] 

Kevin Hawkins commented on CB-1506:
---

I have thoughts on 1, as it's a requirement for us in our local version of 
ChildBrowser.  I can share the approach we've decided to attempt, after 
investigating our options, if that's helpful.  I agree with Jesse; it's not 
trivial.  But I think we have a light at the end of the tunnel.

> Implement InAppBrowser feature
> --
>
> Key: CB-1506
> URL: https://issues.apache.org/jira/browse/CB-1506
> Project: Apache Cordova
>  Issue Type: New Feature
>  Components: Android, iOS
>Affects Versions: Master
>Reporter: Shazron Abdullah
> Fix For: 2.3.0
>
>
> See: http://wiki.apache.org/cordova/InAppBrowser
> Tentatively set for 2.3.0 to get the ball rolling, and only for iOS and 
> Android. Not sure what other platforms this should apply to, if so, add a 
> sub-task.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1506) Implement InAppBrowser feature

[Kevin Hawkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13491750#comment-13491750
 ] 

Kevin Hawkins commented on CB-1506:
---

Incidentally, I'm excited to see ChildBrowser-type functionality becoming a 
first-class citizen in Cordova!  We would eventually like to contribute back 
the changes we've made to an older version of ChildBrowser (significantly, 
functionality for secure viewing of content files on the device, via Safari's 
content preview functionality), and I think pulling InAppBrowser into the core 
code base will help to ease the maintenance from the standpoint of a "single 
source of truth".  +1 to this New Feature!

> Implement InAppBrowser feature
> --
>
> Key: CB-1506
> URL: https://issues.apache.org/jira/browse/CB-1506
> Project: Apache Cordova
>  Issue Type: New Feature
>  Components: Android, iOS
>Affects Versions: Master
>Reporter: Shazron Abdullah
> Fix For: 2.3.0
>
>
> See: http://wiki.apache.org/cordova/InAppBrowser
> Tentatively set for 2.3.0 to get the ball rolling, and only for iOS and 
> Android. Not sure what other platforms this should apply to, if so, add a 
> sub-task.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1822) Move cordova.ios.js to CordovaLib directory

[Kevin Hawkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492556#comment-13492556
 ] 

Kevin Hawkins commented on CB-1822:
---

What are the details around removing/moving VERSION?  With our current 
framework, which consumes Cordova and presents our own "version" of a hybrid 
app framework, it's helpful that the version is parseable, as we do not make 
use of the Cordova app creation template/code, so we have to recreate this 
process to a degree.

Can we keep the version information as something that's somewhat externally 
parseable, as opposed to, say, tightly coupling it with the creation script?

> Move cordova.ios.js to CordovaLib directory
> ---
>
> Key: CB-1822
> URL: https://issues.apache.org/jira/browse/CB-1822
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: Andrew Grieve
>Assignee: Andrew Grieve
>Priority: Minor
> Fix For: 2.3.0
>
>
> Relevant ML thread: http://callback.markmail.org/thread/5m5qiv3vokwyuxyo
> This change involves:
> 1. Move from bin/templates/project/www/{cordova-VERSION.js to 
> CordovaLib/cordova.ios.js 
> 2. Remove VERSION from bin/templates/project/www/index.html
> 3. Move VERSION-adding logic from Makefile into the create script, and have 
> it also copy the .js from the new location
> 4. Delete CordovaLibTests/CordovaLibApp/www/cordova.ios.js
> 5. Add a build phase to CordovaLibApp to copy the .js file into it's www

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (CB-1822) Move cordova.ios.js to CordovaLib directory

[Kevin Hawkins (JIRA)]

[ 
https://issues.apache.org/jira/browse/CB-1822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13492578#comment-13492578
 ] 

Kevin Hawkins commented on CB-1822:
---

Great, thanks!  That will work perfectly for us. ;-)

> Move cordova.ios.js to CordovaLib directory
> ---
>
> Key: CB-1822
> URL: https://issues.apache.org/jira/browse/CB-1822
> Project: Apache Cordova
>  Issue Type: Bug
>  Components: iOS
>Reporter: Andrew Grieve
>Assignee: Andrew Grieve
>Priority: Minor
> Fix For: 2.3.0
>
>
> Relevant ML thread: http://callback.markmail.org/thread/5m5qiv3vokwyuxyo
> This change involves:
> 1. Move from bin/templates/project/www/{cordova-VERSION.js to 
> CordovaLib/cordova.ios.js 
> 2. Remove VERSION from bin/templates/project/www/index.html
> 3. Move VERSION-adding logic from Makefile into the create script, and have 
> it also copy the .js from the new location
> 4. Delete CordovaLibTests/CordovaLibApp/www/cordova.ios.js
> 5. Add a build phase to CordovaLibApp to copy the .js file into it's www

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CB-1830) iOS: CDVViewController's wantsFullScreenLayout property should not be set

[Kevin Hawkins (JIRA)]

Kevin Hawkins created CB-1830:
-

 Summary: iOS: CDVViewController's wantsFullScreenLayout property 
should not be set
 Key: CB-1830
 URL: https://issues.apache.org/jira/browse/CB-1830
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: Master
Reporter: Kevin Hawkins
Assignee: Shazron Abdullah


In [CDVViewController __init], CDVViewController.wantsFullScreenLayout is set 
to YES.  The effect of this property is to ignore the status bar layout, for 
apps that want their views to take space underneath a (presumably translucent) 
status bar.

This should not be the default behavior for a Cordova app, and causes a lot of 
additional configuration of CDVViewController's main view, which otherwise 
would not be necessary.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CB-1831) iOS: App template should not manually configure forced rotation

[Kevin Hawkins (JIRA)]

Kevin Hawkins created CB-1831:
-

 Summary: iOS: App template should not manually configure forced 
rotation
 Key: CB-1831
 URL: https://issues.apache.org/jira/browse/CB-1831
 Project: Apache Cordova
  Issue Type: Improvement
  Components: iOS
Affects Versions: Master
Reporter: Kevin Hawkins
Assignee: Shazron Abdullah


There's a considerable block of code in the app template's AppDelegate for 
trying to control the startup rotation of the app, and force it to a supported 
rotation if the rotation of the device is not supported in the app.

This code is unnecessary; an iOS app will manage this behavior automatically.  
As such, this code can be removed.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CB-1832) iOS: CDVCordovaView should not inherit from UIWebView

[Kevin Hawkins (JIRA)]

Kevin Hawkins created CB-1832:
-

 Summary: iOS: CDVCordovaView should not inherit from UIWebView
 Key: CB-1832
 URL: https://issues.apache.org/jira/browse/CB-1832
 Project: Apache Cordova
  Issue Type: Improvement
  Components: iOS
Affects Versions: Master
Reporter: Kevin Hawkins
Assignee: Shazron Abdullah


CDVCordovaView inherits from UIWebView.  Apple's documentation for UIWebView 
states that classes should not inherit from this class.  Most straightforward 
recommendation is to simply remove CDVCordovaView, and make CDVViewController's 
webView property actually be a UIWebView.  There's currently no custom logic in 
CDVCordovaView to support a custom view anyway.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Created] (CB-1833) iOS: Splash screen imageView's autoresizingMask is not configured properly

[Kevin Hawkins (JIRA)]

Kevin Hawkins created CB-1833:
-

 Summary: iOS: Splash screen imageView's autoresizingMask is not 
configured properly
 Key: CB-1833
 URL: https://issues.apache.org/jira/browse/CB-1833
 Project: Apache Cordova
  Issue Type: Bug
  Components: iOS
Affects Versions: Master
Reporter: Kevin Hawkins
Assignee: Shazron Abdullah


In [CDVViewController showSplashScreen], the imageView property's 
autoresizingMask is comprised of UIViewAutoresizing values that are 
bitwise-ANDed together.  These should be bitwise-ORed together.  The net effect 
is that the view inadvertently does not support autoresizing: its resultant 
value will always be 0 (UIViewAutoresizingNone).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira