• Bug 25444 has been marked as a duplicate of this bug. ***

(In reply to comment #1)

• Bug 25444 has been marked as a duplicate of this bug. ***

Copying here my comment from Bug 25444:

If a user clicks in the reply button of a comment,
it is shown the image ajax-loader.gif. This is ok.

The problem is: sometimes nothing happens (probably
because of slow internet connection) and then a user
clicks the button again. In this case, the image is
added two times. If the user clicks again and again,
it will be added new copies of that image for each click.
This should be avoided.

Notice that if more than one image was shown,
when the script finishes loading the box for new
comments, only the first image will be removed,
causing the impression that there still have something to wait...

Proposed gerrit change I37f195af to fix this.

Currently the behavior is as follows:

1. Click on "Start a new discussion" in some talk page
2. Type something in the edit box
3. Click preview
4. It will execute "liquidThreads.doLivePreview" and then "window.doLivePreview" (which adds the spinner until the preview is complete)
5. Click preview
6. It will execute "window.doLivePreview" (which adds a spinner until the preview is complete), then "liquidThreads.doLivePreview", which calls "window.doLivePreview" again (adding the second spinner)

After gerrit change I37f195af it will be like this:

1. Click on "Start a new discussion" in some talk page
2. Type something in the edit box
3. Click preview
4. It will execute "liquidThreads.doLivePreview" and then "window.doLivePreview" (which adds the spinner until the preview is complete)
5. Click preview
6. It will execute only "window.doLivePreview"

• Bug 35524 has been marked as a duplicate of this bug. ***

(In reply to comment #3)

Proposed gerrit change I37f195af to fix this.

Status Merged, bug maybe resolved

Helder: Is this bug report resolved by the aforementioned Gerrit merge?

Helder: Is this bug report resolved by the aforementioned Gerrit merge?

I can confirm that clicking multiple times the preview button before the preview finishes loading, still adds multiple spinners, and opening the network console one can see the browser still does multiple api POST requests. Multiple spinners are created (although only one is visible), but when the slowest request has finished loading all spinners are removed (each request removes it's own spinner)

Decreasing importance/priority since that doesn't overwrite the edit form nor leaves spinners around after finishing.

In fact, I don't know if this should be improved or not. Locking the buttons until the preview has finished loading can cause problems if the preview request fails (and LQT can't gracefully detect that situation to re-enable them again).

I can no longer reproduce this.

LiquidThreads has been replaced by StructuredDiscussions on all Wikimedia production wikis (except one, which will be done soon). It is no longer under active development or maintenance, so I'm re-classifying all open LQT tasks as "Lowest" priority.