BatchModification can't be used when JavaScript is disabled

[Ryan J Ollos <ryan.j.ollos@…>]

The column of checkboxes is added by JavaScript code, so there is no way to select tickets when JavaScript is disabled. As far as I know, Trac still has the goal of being providing full basic functionality without JavaScript.

Therefore I propose to create a patch that moves addition of the checkboxes to the template. This would also be a good opportunity to put a few functional tests in place for the BatchModify functionality.

If we don't wish to provide BatchModify when JavaScript is not present, then alternatively I'd propose that the Batch Modify form controls be hidden when JavaScript is not present. This could probably be accomplished by hiding them by default in the CSS, and having the JavaScript code set them visible.

[Christian Boos]

Replying to Ryan J Ollos <ryan.j.ollos@…>:

The column of checkboxes is added by JavaScript code, so there is no way to select tickets when JavaScript is disabled. As far as I know, Trac still has the goal of being providing full basic functionality without JavaScript.

No.

Therefore I propose to create a patch that moves addition of the checkboxes to the template. This would also be a good opportunity to put a few functional tests in place for the BatchModify functionality.

No.

If we don't wish to provide BatchModify when JavaScript is not present, then alternatively I'd propose that the Batch Modify form controls be hidden when JavaScript is not present. This could probably be accomplished by hiding them by default in the CSS, and having the JavaScript code set them visible.

I think that would be OK.

[Ryan J Ollos <ryan.j.ollos@…>]

Replying to cboos:

Therefore I propose to create a patch that moves addition of the checkboxes to the template. This would also be a good opportunity to put a few functional tests in place for the BatchModify functionality.

No.

Just for my own education, could you help me understand why you don't want to go this route?

[Christian Boos]

Replying to Ryan J Ollos <ryan.j.ollos@…>:

Replying to cboos:

Therefore I propose to create a patch that moves addition of the checkboxes to the template. This would also be a good opportunity to put a few functional tests in place for the BatchModify functionality.

No.

Just for my own education, could you help me understand why you don't want to go this route?

TracDev/Performance#Genshi is a good place to start ;-)

This translates into: we don't want more Genshi and less JavaScript, but rather the opposite. While this hasn't been "officially" discussed on trac-dev, I think there seems to be a common understanding that this would be a good thing.

But this shouldn't prevent us to think about possible functional testing strategies (e.g. using ​http://phantomjs.org perhaps as described here ​Python Testing - PhantomJS with Selenium WebDriver, or using ​http://jeanphix.me/Ghost.py).

[Ryan J Ollos <ryan.j.ollos@…>]

Replying to cboos:

… While this hasn't been "officially" discussed on trac-dev, I think there seems to be a common understanding that this would be a good thing.

I remember you mentioning this on the trac-dev list just after the release of 1.0, when describing how to move forward with Genshi in light of the performance issue. I had just thought that the official stance was still for graceful degradation. I'm not for/against any particular strategy, so I'm happy to proceed with the patch per your suggestion, and I suppose by hiding the non-functional batch modify form when JS is not prsent, that can be considered graceful degradation.

But this shouldn't prevent us to think about possible functional testing strategies

Ah, I'm glad you mentioned. I'd been thinking about raising a similar question on the mailing list lately. I'll take a look.

In light of the feedback I propose (simply because this is how I've seen it done before):

• Hide the elements by setting the display:none property.
• Add a visible class that has the display:inline property.
• Add the visible class using JavaScript.

I haven't looked closely at the code yet, but just wanted to sketch out the patch to make sure I'm on the right track.

[Christian Boos]

Replying to Ryan J Ollos <ryan.j.ollos@…>:

…

• Add a visible class that has the display:inline property.
• Add the visible class using JavaScript.

or simply a $("...").show() of the appropriate stuff at document load time.

[Ryan J Ollos <ryan.j.ollos@…>]

Thanks. I will work up a patch after I complete the other 3 tickets I'm working at the moment.

[Remy Blank]

Replying to cboos:

This translates into: we don't want more Genshi and less JavaScript, but rather the opposite. While this hasn't been "officially" discussed on trac-dev, I think there seems to be a common understanding that this would be a good thing.

I tend to agree with that, too, but we indeed never discussed it. AFAIK except for batch ticket changes, Trac always has a "degraded" mode for all functionality requiring JavaScript. If we re-visit this decision, we should probably also remove these fallbacks.

[Ryan J Ollos <ryan.j.ollos@…>]

I didn't see how to use ​show since it restores the display property to what is was originally, however we can change the css directly by calling css: t11014-r11483-1.patch​. Alternatively, we can use a class to keep the properties in the css: t11014-r11483-2.patch​.

[Remy Blank]

Replying to Ryan J Ollos <ryan.j.ollos@…>:

I didn't see how to use ​show since it restores the display property to what is was originally,

Did you try? Just calling .show() on the form does the trick. Patch applied in [11507], using .show() and calling it at the very bottom, when everything is set up.

[Ryan J Ollos <ryan.j.ollos@…>]

Replying to rblank:

Did you try?

I hadn't tried. I guess I was depending too much on the documentation (or my interpretation of the documentation).

Thanks though, that one-liner will be useful in a plugin I'm working on as well.