JavaFX 8.0 WebView: allDocs.then() when using HTTP returns the number 6

[yaronyg]

Scenario:

I am using JavaFX 8.0 WebView plus pouchdb-localstorage-down.js

db.allDocs({include_docs: true}).then(function(result) { .. })

The request is issued for a local DB.

Expected Result:

That the result variable will contain an allDocs result object with a total_rows property, offset property, rows, property, etc.

Actual Result:

The number 6 (note that the actual number of rows is 12 in my test)

Note

If I submit a callback the function works just fine. So the problem is specifically with getting the result via then().

[calvinmetcalf]

something is really screwed up with JavaFX 8.0 WebView

[nolanlawson]

@yarong could you provide a set of instructions for how to test against JavaFX, or maybe even a build script? More automation is always nice, and it helps us verify what you're seeing.

[yaronyg]

So this and a bunch of other JavaFX bugs have driven me to the point where I'm ready to just give up on JavaFX 8.0 WebView all together. I want to be a good member of the PouchDB community and I can find a few hours to set up something you can play with next week (have a public demo I have to get squared away first). But let's be honest, if I just shut up about this and the other JavaFX bugs would anyone care? Because one of the many reasons why I'm thinking of going away from JavaFX 8.0 WebView is that it feels like nobody but me is actually using it! What do you think?

[calvinmetcalf]

I honestly never heard of it before you brought it up, @nolanlawson you do java stuff, your take ?

[nolanlawson]

I had never heard of JavaFX WebView until @yaronyg brought it up.

That being said, you're not bothering anyone by fixing bugs in exotic browsers. I'm currently working on Android 4.3 and IE 10/11, and we only recently got Safari and iOS tests passing at 100%. I imagine JavaFX is somewhere between IE9 and Android 2.x in terms of difficulty to get running, but that doesn't mean there's no value in fixing it. And since JavaFX is partially open-source, some of your fixes could maybe even filter back into the JavaFX codebase itself.

It's an open-source project, so work on whatever strikes your fancy and don't feel bad about it. :)

[yaronyg]

The problem is not fixing bugs in exotic browsers. It's about NOT fixing bugs in exotic browsers. Jon and I (the Thali folks) have decided to abandon JavaFX for now. So my preference would be to just forget about this bug. I figure we shouldn't close it since it's real and if someone else runs into it they should be able to see it. But otherwise, I just don't care. So does anyone mind if I ignore this bug? Or would they prefer if I actually closed it?

[daleharvey]

Yeh if you want to pick up fixes from the general contributions then aligning on a platform that other people are using is gonna benefit you, if you had a requirement to use JavaFX then we would love to support it in pouch, but fixing its bugs would usually end up being down to you as one of its rare users

I would close out any of the bugs you dont dont need to worry about, there are a million platforms we 'could' support, and I would rather we just track the ones current users care about

I will take a start and close out this one :)

[nolanlawson]

I modified the title to reflect that this is just in JavaFX WebView.

[yaronyg]

@daleharvey - Amen :)
@nolanlawson - Thanks