Clicking 'Submit' or 'Modify Ticket' from comment edit is blocked by comment preview function

[txcraig@…]

Here is the scenario:

• I am adding a comment to a ticket by typing in the textarea (Firefox 4.0)
• I finish typing my comment and am ready to submit, so use the mouse to click the Submit changes button
• the wiki-preview of the comment is updated but the ticket is not updated - i.e. I am still in edit mode.
• I have to click Submit changes again to update the ticket

It took a few times of this happening before I realized that probably the "lost focus" handler that updates the preview was firing just before the button click, and was therefore preventing the submit from happening.

The other note is that this is not 100% reproducible - sometimes the submit goes through, other times it does not. It seems like only the first time the wiki preview is updated the problem exhibits - after that it works as expected.

Trac 	0.12
CustomFieldAdmin 	0.2.2
Docutils 	0.6
Genshi 	0.6
mod_python 	3.3.1
pysqlite 	2.3.2
Python 	2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)]
RPC 	1.1.2-r0
setuptools 	0.6c9
SQLite 	3.3.4
Subversion 	1.6.6 (r40053)
jQuery:	1.4.2

[rblank]

What happens quite often is that the "Submit" button is pushed down by the preview at the precise moment when I try to click it, so I click on the preview instead. Then I have to scroll down, find the button again and click it.

It's a minor annoyance, and I have taken the habit of waiting for two seconds before clicking "Submit". Also, the progress indicator on trunk should make it more explicit when a preview operation is in progress. Other than that, I don't know what we could do to improve the situation. Suggestions welcome.

[txcraig@…]

Thanks for taking a look at this.

pushed down by the preview at the precise moment

It looks like the 'blur' event is the one causing this. Is there any reason why blur is needed as a trigger for the update? Seems like the timeout on the keydown/keypress is sufficient. If blur was taken out, then at least you would vastly reduce the chances that the update happens at the same moment you click the button. You could further reduce the odds by having mousemove reset the timer (as I am moving my mouse down to submit, it ensures the preview is not updated for a bit).

It's a minor annoyance, and I have taken the habit of waiting for two seconds

Agreed it is a minor issue. I never thought of waiting the 2 seconds. For new users especially this might be a bit of a head-scratcher.

the progress indicator on trunk should make it more explicit when a preview operation is in progress.

Aha, I see the progress indicator on this Trac, cool! I don't think it has any effect on this problem though, since the "push down" happens just before the progress indicator starts.

I was wondering why I was not seeing this problem on the Edgewall Trac, then it occurred to me that since my Trac is on the LAN the response time is so much quicker - that must be the difference.

[rblank]

Replying to txcraig@…:

It looks like the 'blur' event is the one causing this. Is there any reason why blur is needed as a trigger for the update? Seems like the timeout on the keydown/keypress is sufficient. If blur was taken out, then at least you would vastly reduce the chances that the update happens at the same moment you click the button.

Not quite. The blur event triggers an update only if the content has changed since the last update, in which case the timer has already been started, and the update will be triggered anyway. It's all a matter of timing. However…

You could further reduce the odds by having mousemove reset the timer (as I am moving my mouse down to submit, it ensures the preview is not updated for a bit).

… that's a very nice idea. I'll experiment with the idea and see if it improves the situation. So this is related to #7145.

Agreed it is a minor issue. I never thought of waiting the 2 seconds. For new users especially this might be a bit of a head-scratcher.

Yes, agreed.

Aha, I see the progress indicator on this Trac, cool! I don't think it has any effect on this problem though, since the "push down" happens just before the progress indicator starts.

I was wondering why I was not seeing this problem on the Edgewall Trac, then it occurred to me that since my Trac is on the LAN the response time is so much quicker - that must be the difference.

You can also tune the delay before the update is triggered. It's set to two seconds here.

[cboos]

Is this a Firefox issue only? Never noticed that with Chrome…

[cboos]

Ok, indeed, I've just experienced it with Firefox, although it's not easy to reproduce.

For the fix, I'd prefer something deterministic rather than relying on mouse moves or timings. For example, can't we cancel the effect of the preview action when the submit button gets pressed?

[rblank]

Replying to cboos:

For the fix, I'd prefer something deterministic rather than relying on mouse moves or timings. For example, can't we cancel the effect of the preview action when the submit button gets pressed?

That's a good idea, too. It will solve the issue of the OP, but not the moving buttons.

[lkraav <leho@…>]

Definitely thanks to the OP for taking the time to report this annoyance :)

[txcraig@…]

can't we cancel the effect of the preview action when the submit button gets pressed

I was under the impression the submit button moved before it ever got a chance to be pressed

thanks to the OP for taking the time to report this annoyance

Thanks to everyone for working on the issue. I really should have attempted a fix myself and proposed a patch, but I don't have a dev environment setup for Trac yet. Hope to do that soon.

[txcraig@…]

Along with "clicking Submit", "clicking Modify Ticket" exhibits the same issue for me, it scoots out of the way and remains unexpanded. I have to click Modify Ticket a 2nd time to get it to expand. This is a very common case to add a comment and then modify the ticket to update the time spent or other fields.

It's likely that any fix for the Submit button would also fix Modify Ticket, but just to be complete I wanted to note this. Tweaked the Summary to reflect this.

[cboos]

Replying to txcraig@…:

Along with "clicking Submit", "clicking Modify Ticket" exhibits the same issue for me, it scoots out of the way and remains unexpanded.

Hm, you may have an "intermediate" trunk version, I suppose. The dynamic preview currently appears below the Modify Ticket heading, so the latter can't jump down like the |Preview| and |Submit| buttons might do.

But this also suggests we could fix the problem by moving those buttons on that line:

+---------------------------------------+
|                                       |
+---------------------------------------+
> Modify Ticket       |Preview|  |Submit|

I think that would also fit well with some pending changes I have for #10012 that style the "actionable" headings a bit like buttons.

We could also duplicate the buttons at the bottom of the dynamic preview:

+---------------------------------------+
|                                       |
+---------------------------------------+
V Modify Ticket       |Preview|  |Submit|

 ....
 ...
 ..

 --------------------------------------- 
| Changed by ...                        |
|                                       |
 --------------------------------------- 
 |Preview|  |Submit|         Attachments^

i.e. only visible when the preview is shown.
Note that the second |Preview| button is probably not needed when the automatic preview is active.

[rblank]

I have finally experienced the effect explained by the OP. If you have a very fast server, the time between the blur event of the comment <textarea> and the click event of the button is enough for the preview to appear, and the button to be pushed down and therefore the click event doesn't even happen. This is due to the blur event triggering a request directly, instead of triggering the update timer. I will change that so that all events just trigger the timer, and this should fix the original issue.

I will also experiment with duplicating the buttons as suggested in comment:10.

[rblank]

Changed the blur event to generate a delayed request in [10742].