Nightly build #236 for cordova has succeeded!
The latest nightly has been published and you can try it out with 'npm i -g
cordova@nightly'
For details check build console at
https://builds.apache.org/job/cordova-nightly/236/consoleFull
-
Jenkins for Apache Cordova
Ideally we'd get Apache infra to fix up the VM, and we could build
some bandwidth caps into it and better monitoring into the instance to
get some more visibility into the situation should it go off the rails
again.
In the mean time, we should look at alternatives. I'll look into
hosting an
Thanks Kerri!
These failures below shouldn't affect release, they are plugin failures.
I'm having 4 failures in mobile-spec iOS:
file.spec.147
media.spec.21
media.spec.22
media.spec.27
I worked around the file-transfer errors (I believe we can't run the server
on cordova-vm now) through
Microsoft emails are still being sent to spam for me (using Gmail) so I
didn't see this until later.
You said: "should we care about specification or about functionality?"
We care firstly about what we documented. In this case, according to our
docs, chunkedMode defaults to true, and in our
Github user pke commented on the issue:
https://github.com/apache/cordova-plugin-device/pull/57
But that is not the name the user gave the device, is it?
The `name` property has been deprecated here before. I think this PR is not
complete without readme changes and implementations
Github user fredgalvao commented on the issue:
https://github.com/apache/cordova-android/pull/332
@macdonst Hmm, I think I found something strange.
This is still open, even though the code is on master. Commit
Yep. Have we reached 100 repos yet?
On Wed, Nov 23, 2016 at 10:07 AM Shazron wrote:
> No brainer +1
> Yuuge!
>
> On Tue, Nov 22, 2016 at 5:30 PM, Steven Gill
> wrote:
>
> > Right now, cordova-lib git repo [1] has cordova-serve, cordova-common,
> >
Github user cordova-qa commented on the issue:
https://github.com/apache/cordova-plugin-file-transfer/pull/169
Cordova CI Build has one or more failures. Link:
http://cordova-ci.cloudapp.net:8080/job/cordova-plugin-file-transfer-pr/45/
312 tests run, 26 skipped, 51 failed.
No brainer +1
Yuuge!
On Tue, Nov 22, 2016 at 5:30 PM, Steven Gill wrote:
> Right now, cordova-lib git repo [1] has cordova-serve, cordova-common,
> cordova-fetch & cordova-lib modules. This is an anti-pattern in node. You
> can't install any of those modules via gitURL
+1 Doit!
@purplecabbage
risingj.com
On Wed, Nov 23, 2016 at 7:40 AM, wrote:
> A huge +1 from me!
>
> Sent from my phone.
>
> > On Nov 22, 2016, at 19:30, Steven Gill wrote:
> >
> > Right now, cordova-lib git repo [1] has cordova-serve,
Github user mccraigmccraig commented on the issue:
https://github.com/apache/cordova-plugin-wkwebview-engine/pull/16
if it is `about:blank` that would mean one of
1. the `onAppWillEnterForeground` callback isn't firing
2. there is a bug in the `onAppWillEnterForeground`
Github user mccraigmccraig commented on the issue:
https://github.com/apache/cordova-plugin-wkwebview-engine/pull/16
hmm - that would seem to indicate that it is a different bug, or that the
WSOD has some other URL than `about:blank` ?
---
If your project is set up for it, you can
Github user pwbs commented on the issue:
https://github.com/apache/cordova-plugin-wkwebview-engine/pull/16
Since it's a non-inspectable version, I can't be sure that it's actually
`about:blank`, although I'd bet it is.
(I'm using iOS10 and with the inspectable versions I
Github user pwbs commented on the issue:
https://github.com/apache/cordova-plugin-wkwebview-engine/pull/16
I've just observed it with a non-inspectable version: it's not recovering
after back/foregrounding the app. :-/
---
If your project is set up for it, you can reply to this
A huge +1 from me!
Sent from my phone.
> On Nov 22, 2016, at 19:30, Steven Gill wrote:
>
> Right now, cordova-lib git repo [1] has cordova-serve, cordova-common,
> cordova-fetch & cordova-lib modules. This is an anti-pattern in node. You
> can't install any of those
There is a related issue on Ios platform [3] - having chunkedMode=true causes
progress not to be computable as we don't include Content-Length header to the
request in this case.
Reverting that logic fixes the onprogress event but breaks our tests - so this
is a question again - should we care
Github user craig-at-rsg commented on the issue:
https://github.com/apache/cordova-plugin-file-transfer/pull/141
@raykin Haven't found a workaround - reverted to the older version of this
plugin.
---
If your project is set up for it, you can reply to this email and have your
reply
Github user romedius commented on the issue:
https://github.com/apache/cordova-plugin-camera/pull/220
Permission management has been changed and cleaned up. Issue seems to be
deprecated.
@Gorcyn can you confirm this?
---
If your project is set up for it, you can reply to this
Github user romedius commented on the issue:
https://github.com/apache/cordova-plugin-camera/pull/220
Why are we only checking for one permission, we would need both, right?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as
Hi guys,
There were several user reports recently about the upload failures caused by
the lack of Content-Length header in case of HTTPS uploads.
This issue is caused by the FileTransfer code, which forces chunkedMode=true
for HTTPS uploads due to possible OutOfMemoryException.
As a solution
GitHub user daserge opened a pull request:
https://github.com/apache/cordova-plugin-file-transfer/pull/169
CB-10974 Cordova file transfer Content-Length header problem
### Platforms affected
Android
### What does this PR do?
Don't force chunkedMode=true
Github user vukdavid commented on the issue:
https://github.com/apache/cordova-plugin-file-transfer/pull/141
Facing same HTTP 411 issue: "A request with the POST method requires a
valid Content-Length header."
Using android with latest plugin versions:
22 matches
Mail list logo