On Wed, Apr 30, 2014 at 1:30 PM, Joe Bowser <[email protected]> wrote:
> On Wed, Apr 30, 2014 at 9:35 AM, Michal Mocny <[email protected]> wrote: > > On Wed, Apr 30, 2014 at 12:23 PM, Joe Bowser <[email protected]> wrote: > > > >> Hey > >> > >> So, once again, we're dealing with some major API changes once we > >> introduce pluggable webview. The first change that was done for > >> sanity was finally deprecating setProperty. This was slated to be > >> removed by 3.5 or in six months from the deprecation date, but we kept > >> it in too long. While I would like to assume that everyone has moved > >> over to setting their preferences in config.xml, which is the much > >> more sane way of doing things, we can't do that. We need to publicize > >> this in some blog posts, as well as in our documentation somehow. > >> There will obviously be some pissed off users, as we've seen in past > >> posts, but I think having the ability to use a WebView other than > >> Chrome 30 is worth these changes. > >> > > > > Is it feasible to leave setProperty working only for default WebView? > This > > would mean that custom webviews won't work with older plugins, but I > think > > thats fine. > > > > The setProperty methods are actually in Cordova-Activity, and we could > re-add those. The thing is that these aren't actually used by > plugins, and instead are legacy methods that only our unit tests use. > I'll put them back in. > > > > >> > >> The other change, which says more about our design is adding a getter > >> method for pluginManager. We need to access the pluginManager to get > >> plugins, and it's expected that everyone who implements a > >> CordovaWebView will have this method produce a pluginManager. In the > >> past, it was just publicly exposed, which was not the greatest idea > >> and was kinda sloppy. > >> > > > > Similar to above question, could we leave it (deprecated) as an exposed > > property only on the default webview? And only support the new getter > for > > new webviews (xwalk, gecko)? Again, only updated plugins would work with > > custom webview, but I think thats fine. > > > > No, I don't think so. It's probably better to make a clean break and > have all the WebViews expected to function the same than to have some > plugins simply fail with certain webviews. Plugins breaking across > all the WebViews will force people to fix them, while things breaking > with only Crosswalk will put crosswalk at an unfair disadvantage. > Trust me, Crosswalk is going to have an unfair *advantage* regardless of plugin support ;)
