search

praeclarum / Ooui

A small cross-platform UI library that brings the simplicity of native UI development to the web
MIT License
1.62k stars 160 forks source link

WebView, the only limitation in large application, we can't find a proper fix #222

Open Psercom opened 5 years ago

Psercom commented 5 years ago

In furtherance of issue #217 it's amazing how well this magnificent component has worked on a large, involved application with complicated navigation (using our own nav stack manager), etc. The one limitation noted is that WebView isn't compatible, even in a minimalist test, with a button on the same page. Running a full build of Ooui source in debug mode we note that WebView leaves the message pump not running. Exit from app.use is premature with WebView present for reasons we haven't yet identified despite seeming lack of differences leaving ExecuteResultAsync. It does not appear to be a race condition. It would be good to resolve this issue since we believe that would make Ooui sufficiently ready for general usage in major applications more involved than the various test and demo apps demonstrating effective handling of individual controls. Thanks for a wonderful contribution.

Psercom commented 5 years ago

request to ooui.js path is not initiated, nor subsequently to websocketpath ooui.ws, as they are when webview is not on page.

Psercom commented 5 years ago

The WebView issues are not side effects of the vagaries of our own code. A simple environment to demo and test the dead buttons is had by simply building the sample jamesmontemagno/MyFirstOouiApp and then adding this line to its page:

The button on this page becomes unresponsive with no message pump active, and the middleware pipeline never requesting ooui.js nor ooui.ws.

Psercom commented 5 years ago

The line to add:

Psercom commented 5 years ago 
        <WebView Source="TESTURL"></WebView>
Psercom commented 5 years ago

While the problem originates from having among a page's children any active element such as a button plus an (offending) WebView, the unresponsiveness of these elements results not initially but from the outside wherein e.g. MVC does not do page requests on ooui.js or the ooui socket message file to establish the message pump. We can imagine a spoofing kludge/fix as the remaining http response comes in, but this would not be correct. To solve the problem it seems one needs to run with the debugging versions of open source mvc, xamarin forms, etc., the controllling components outside ooui itself that fail to generate the proper http requests. We've spent time and tried to find the problem but have decided a quality solution by Frank is required to maintain the extremely high code quality we've observed while stepping through ooui in the debugger. It's disappointing we can't forge ahead since we have so much of a very large application (a cross platform code generator operating off of only declarative xml) running and have gotten so close. Hopefully, Frank might, when he can, address this one serious limitation in all the code we ported into the ooui magnificent and amazing environment. In the meantime, anticipating that we can eventually be successful, we are grateful for all that has been achieved.