Bug #1902
closedProgressive enhancement bootstrap never...progresses
0%
Description
It is my understanding that progressive enhancement should progress like this:
HTML -> Javascript -> AJAX long poll -> Web sockets
This was, indeed, almost letter for letter what your report from a while back detailed.
Unfortunately, this seems not to be the case: in the GIT and 3.3.0 version of WT, progressive enhancement when set causes the environment to report that the browser does not support javascript, and there is no upgrade to javascript, AJAX, and certainly not web sockets at any point, even after an hour or multiple signals sent to server, despite the fact that my browser certainly supports javascript (and all major browsers were tried, just to make sure).
The default graceful degrading bootstrap works absolutely fine; on all major browsers upgraded to websockets immediately in fact.
My original test was with WT GIT, derived from winst, and with Chrome, Chrome Canary, and Firefox. I used the example "hello" program, and augmented it with returning environmental information for javaScript() and ajax().
Files
Updated by Wim Dumon over 11 years ago
- Status changed from New to Feedback
Hello Alice,
Watch out how you test this feature. For progressive bootstrap, Wt first renders the page as plain HTML, and will also let your widgets know that this is the intention, by having WEnvironment::aja() return false. It's only after that it has been detected that JS is available, that WApplication::enableAjax() will be called. This will be propagated to all widgets, so that the entire widget tree is updated to include JS support.
Read also http://www.webtoolkit.eu/wt/doc/reference/html/overview.html#progressive_bootstrap
So to detect the progression, you can either override WApplication::enableAjax() (set your message there), or print the value of WEnvironment::ajax()in the greeting method - at that time the promotion from plain HTML to JS should be completed.
We use the progressive bootstrap feature on our homepage, so we're pretty sure that it works. If with the test method described above you still see that it does progress, please let me know so that we can investigate.
BR,
Wim.
Updated by Alice Margatroid over 11 years ago
I did that in my original test, but I had a few hours, so I pulled a fresh copy from GIT and created this test case:
Merging in both your override suggestion as well as a button you can use to check if the promotion ever occurs.
The results are pretty conclusive:
http://i.imgur.com/tvEhzz5.png
For clarity, that is:
Left to bottom: Chrome dev, Chrome Canary, Opera (latest) IE10
Right to bottom:
Firefox (normal), Firefox (Aurora), Safari, and IE6
This test was repeated on no less than three different desktop machines, running OSX and GNU/Linux (Gentoo to be exact) as well as a WebOS tablet and phone, and an android based tablet.
All results come out identical. None except IE caused WT to upgrade to JS or AJAX.
Furthermore, even IE did not upgrade to WebSockets, despite that occuring in every browser with graceful degrading bootstrap. If the results had been more mixed, I would have tested server push to see if that would upgrade it to websockets, but clearly that's not necessary at this time.
I'd happily accept that it's in some way my ignorance of WT causing this problem (despite having worked with WT enthusiastically since before V.3), but less than a week ago it contained a simple error that prevented it from working at all on any major browser (besides IE again, which happily ignored it). As my test shows, I'm pretty sure it doesn't work.
Updated by Koen Deforche over 11 years ago
- File wt_config.xml wt_config.xml added
- Assignee set to Koen Deforche
Hey,
Thanks for the test case. I tried it now with current git and Firefox, Opera, and Chrome, but all work as expected. Clearly we are not doing the same thing. I am testing using the built-in httpd, are you using that connector too?
There might be something with your configuration file that is causing the discrepancy, or there is a build problem.
Attached is a configuration file that I used for testing.
Regards,
koen
Updated by Alice Margatroid over 11 years ago
It appears your XHTML1 support has been severely damaged somewhere since 3.2.2: this is the second error that's come down to XHTML1 validation I've found.
true
causes the error I am currently reporting: progressive enhancement will never enhance as long as XHTML mime type is enabled. I assume IE works with my use case because IE does not support this mime type.
Does the XHTML mime type interfere with javascript or AJAX in such a way that would prevent updating to a full AJAX'd web app?
Please advise,
Alice
Updated by Koen Deforche over 11 years ago
- Status changed from Feedback to Resolved
- Target version set to 3.3.1
Hey,
XHTML1 mime-type got out of fashion since HTML5 includes support for inline SVG, which was the most compelling reason to enable it.
In fact, it seems that the consensus on the demise of XHTML1 is so conclusive, I would actually consider dropping support from it in Wt.
That said, I did just now fix the bug that prevented this progression to work, so you should see this appear in the repo soon.
Really curious though, why do you prefer the XHTML1 mime-type ?
Regards,
koen
Updated by Alice Margatroid over 11 years ago
For debugging purposes, I prefered to enable XHTML1 as it is strict and has broad compatibility (I have a number of WebOS devices which don't fully support HTML5).
Howevever, I would much prefer HTML5, perhaps with HTMLshiv or a number of polyfills that are enabled only when certain HTML5 only features are used. One feature request I submitted was for a color picker that Chrome uses by default, with a polyfill for other browsers to add that support in. A notable example would be WAudio on IE6; it doesn't merely not function, it can actually break the page because IE6 won't style the audio tag at all.
If you wish to remove XHTML1 support, that's fine; none of my uses depend on it exclusively, and there isn't too large of a need for it that HTML5 doesn't fill. But one of the strengths of Wt is how it wall papers over browser and technique differences in javascript, AJAX, and websockets. I think another area it would do to normalize is HTML5 support.
Updated by Koen Deforche over 11 years ago
- Status changed from Resolved to Closed