What exactly would this flag do underneath? I suppose it will add the crosswalk plugin and run it's tests. Am I missing anything else?
> On Jan 27, 2015, at 12:29 PM, Jesse <[email protected]> wrote: > > If you know there will be more, wouldn't it be simpler to just do something > like : > --webview=crosswalk // ? > > Just a small thing. > > @purplecabbage > risingj.com > > On Tue, Jan 27, 2015 at 12:23 PM, Andrew Grieve <[email protected]> > wrote: > >> I think that would be manageable. Especially since right now there is only >> 1. >> >>> On Tue, Jan 27, 2015 at 2:16 PM, Joe Bowser <[email protected]> wrote: >>> >>> I don't know if we want to do that, then we'd have to create flags for >>> every potential third party webview. >>> >>> On Tue Jan 27 2015 at 7:03:28 AM Andrew Grieve <[email protected]> >>> wrote: >>> >>>> Sounds good. We should add a --crosswalk flag to createmobilespec.sh :) >>>> >>>>> On Tue, Jan 27, 2015 at 2:07 AM, Hu, Ningxin <[email protected]> >>>> wrote: >>>> >>>>> Hi Joe, >>>>> >>>>>> >>>>>> Crosswalk has its own release schedule, so it should have its own >>> test >>>>> project >>>>>> somewhere that tests the interfaces that it implements. Of course, >>>> this >>>>>> would be similar to the ones that we still need to write for the >>>>>> AndroidWebView. That said, I think for now we should proceed with >>> the >>>>>> current tests and write the tests for 4.1.x >>>>>> >>>>>> This means that even if Crosswalk doesn't pass the JUnit tests, it >>>> still >>>>> won't >>>>>> hold up the Cordova 4.0 release, because it's Crosswalk failing the >>>>> tests, not >>>>>> Cordova itself. Being independent and interoperable is good, >> since I >>>>>> anticipate Crosswalk to release much more quickly than Cordova. >>>>> >>>>> It makes sense. >>>>> >>>>> From crosswalk-engine testing perspective, let's: >>>>> 1. focus on mobile-spec integration test for Cordova 4.0 release >>>>> 2. maintain the JUnit test project independently and align with 4.1.x >>>>> development >>>>> >>>>> Please let us know if there are anything missed. >>>>> >>>>> Thanks, >>>>> -ningxin >>>>> >>>>>> >>>>>>> On Mon Jan 26 2015 at 10:14:11 PM Fu, Junwei <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Crosswalk engine have been tested with mobile-spec and owned >>>>>>> functionality test, but there are no JUnit test for Crosswalk >>> engine, >>>>>>> and the JUnit test in cordova-anroid 4.0 were being re-wrote. >> Does >>>> the >>>>>>> Crosswalk engine need pass JUnit test before voting on releases? >>>>>>> What's plan about making JUnit test cases to test pluggable >>> webView. >>>>>>> >>>>>>> Thanks, >>>>>>> Junwei. >>>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Joe Bowser [mailto:[email protected]] >>>>>>> Sent: Tuesday, January 27, 2015 7:55 AM >>>>>>> To: dev >>>>>>> Subject: Re: File Transfer plugin and Crosswalk engine cookies >>>>>>> >>>>>>> As far as I'm aware, we're basically waiting for this to be done >>>>>>> before starting the vote thread. Does this code exist yet? >>>>>>> >>>>>>> On Tue Jan 20 2015 at 12:12:22 PM Andrew Grieve < >>>> [email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> I was planning on doing exactly what Darryl described. Would >> love >>>>>>>> such a PR! Note that we've just used this approach for the new >>>>>>>> WebView security >>>>>>>> hooks: >>>>>>>> >>>>>>>> https://github.com/apache/cordova-android/commit/ >>>>>>>> 623b394c830b8a83b5c2f16624d8013b6f851cd9 >>>>>>>> https://github.com/apache/cordova-android/commit/ >>>>>>>> 11002d4a56a4901087f514e2d01f8db392d0abe1 >>>>>>>> >>>>>>>> >>>>>>>> CookieManager has been exposed to plugins for a long time, and >> it >>>>>>>> would be crippling if FileTransfer could not set cookies. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Jan 20, 2015 at 1:48 PM, Joe Bowser <[email protected] >>> >>>>>> wrote: >>>>>>>> >>>>>>>>> I think we should make the File Transfer plugin not need a >>>>>>> CookieManager. >>>>>>>>> It sounds like that's the bigger problem than it having to be >>>> tied >>>>>>>>> to a particular implementation of Cookies. >>>>>>>>> >>>>>>>>> On Tue Jan 20 2015 at 10:32:25 AM Darryl Pogue >>>>>>>>> <[email protected]> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> With the idea of preparing Cordova Android 4.0.x for >> release >>>>>>>>>> starting to come up in discussions, I thought it was worth >>>>>>>>>> raising this as a potential blocker. >>>>>>>>>> >>>>>>>>>> The file transfer plugin uses the Android webview cookie >>>> manager. >>>>>>>>>> When you're using a Crosswalk webview (or GeckoView >>>> presumably), >>>>>>>>>> in the best case there are no cookies with file transfer >>>>>>>>>> requests and in the worst case it will cause the app to >> crash >>>> on >>>>>>>>>> Android >>>>>>> 4.2.x. >>>>>>>>>> >>>>>>>>>> There are a few existing bug reports and PRs related to >> this, >>>>>>>>>> but none of them propose a general solution for different >>>>> webviews. >>>>>>>>>> [1] [2] [3] [4] >>>>>>>>>> >>>>>>>>>> I was looking at this problem last week and the only >> general >>>>>>>>>> solution I could think of would involve adding a >>>>>>>>>> CordovaCookieManager interface and implementing it for each >>>>>>>>>> webview engine, which didn't seem to be the most idea >>>> situation. >>>>>>>>>> >>>>>>>>>> I can write that interface and make a PR for it, but I'd >>> rather >>>>>>>>>> hear if anyone has better ideas before starting to make >>> changes >>>>>>>>>> across multiple repos. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> [1]: >> https://github.com/crosswalk-project/crosswalk-cordova- >>>>>>>>>> android/pull/38 >>>>>>>>>> [2]: >>> https://github.com/apache/cordova-plugin-file-transfer/pull/8 >>>>>>>>>> [3]: >>>>>>>>>> https://github.com/MobileChromeApps/mobile-chrome- >>>>>> apps/issues/46 >>>>>>>>>> 4 >>>>>>>>>> [4]: >>>>>>>>>> https://github.com/gaochun/cordova-plugin-file-transfer/ >>>> commit/ >>>>>>>>>> 0063249e279b99a0feb4601650fc3a4c9e8a8ed2 >> ------------------------------------------------------------ >>>> ---- >>>>>>>>>> -- >>>>>>>>>> --- To unsubscribe, e-mail: >>> [email protected] >>>>>>>>>> For additional commands, e-mail: >> [email protected] >> --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
