Bug #1902


Progressive enhancement bootstrap never...progresses

Added by Alice Margatroid about 11 years ago. Updated almost 11 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


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().


wt_config.xml (140 Bytes) wt_config.xml Configuration file Koen Deforche, 05/17/2013 03:14 PM
Actions #1

Updated by Wim Dumon about 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

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.



Actions #2

Updated by Alice Margatroid about 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:

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.

Actions #3

Updated by Koen Deforche about 11 years ago


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.



Actions #4

Updated by Alice Margatroid about 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.


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,


Actions #5

Updated by Koen Deforche about 11 years ago

  • Status changed from Feedback to Resolved
  • Target version set to 3.3.1


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 ?



Actions #6

Updated by Alice Margatroid about 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.

Actions #7

Updated by Koen Deforche almost 11 years ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF