Replace the ajax-progress-throbber div with a class

Totally agree with this. Theming / overriding the throbber style and location should be trivially easy to do.

Sometimes you want the throbber to reside inside the button itself that is clicked... while other times you may need to position the throbber elsewhere on the page, or display a full-screen overlay to block further input. The patch in #1 makes the first part possible; a follow-up patch that adds a body class (and possibly a companion empty top-level dom element?) would make the later stupid simple. Not to blow the scope completely here, but having an encapsulated way to simply override the throbber javascript in your theme without touching the entire ajax.js file would be clever as well.

Encapsulating the throbber js and css code to allow it to be overridable by a theme is a good candidate for the theme component library.

Here's a first shot at tackling this problem and come up with an usable, extensible way to deal with throbbers.

It replaces the html chunk that got appended to "throbbing" elements with a class named throbbing. I chose this name to make it consistent with what the Autocomplete widget uses.

There's no styling on it yet, but I guess it's a matter of coding css now if this approach gets pushed.

#4: ajax-throbber-class-1490402-4.patch queued for re-testing.

Added CSS for the following elements:

• a
• .button
• input[submit]

Also, untested RTL styling is available.

Added links to related issues.

In D7 and below, in order to change the styling on the throbber, you either have to hack the core or do some very weird css/jquery shennenigans. I know this because once I lost like 3 days trying to come up with the best solution for a client of mine who requested it.

So being able to be style the throbber just by overriding a single class is exactly why I would like this patch to be pushed. If you need me to work on some other patch for other elements tha don't work anymore please link the issues here and I will be happy to do it.

The implementation was recently revised in #1069152: Throbber in textfield is misaligned when browser hardware acceleration enabled (gfx)

As a followup to that I suggested #2181399: Consider moving the animated .GIF throbber outside the autocomplete fields and using CSS animation instead. — which might be a duplicate of some of the related issues.

I'm not sure what the exact deal is here, but in general, "CSS class" sounds good ;)

1. +++ b/core/modules/edit/css/edit.theme.css
   @@ -246,11 +246,24 @@
   +.edit-button.action-save.is-loading {
   

   the throbber.gif is very low quality. It looks very bad on blue background.

2. +++ b/core/modules/system/css/system.module.css
   @@ -4,6 +4,52 @@
   +  background-image: url(../../../misc/throbber.gif);
   ...
   +  height: 18px;
   +  width: 19px;
   

   It's not a big problem but not sure if we possible to find an icon exactly square in size (18 x 18)

I tested this with the latest patch, and on the content type editing form the throbber looks good (as in the previous screenshots) but on the view editing form (and probably on the other dropbuttons) it's half outside of the button.

Concerning the blue background: it's true that the throbber.gif looks very bad on a dark background (to see it: create and save a node > click on the contextual link to quick edit it > make a modification > click Save), and for instance I haven't found a .gif throbber that would look good both on a white and on a colored background. (I don't know if it's possible. Should we use two different throbbers depending on the background?)

By the way, the edit module uses this throbber already (named icon-throbber.gif), so even without the patch the throbber looks bad in the quick edit form. Perhaps we should anyway unify the different throbbers used, as the Views_ui uses still another throbber, loading.gif and loading-small.gif, that has a dark background.

Let's try to get more feedback about what @Outi asked in previous comment.

Should the throbber question be resolved in another issue and use here the existing throbber?

LewisNyman, what admin theme is that in your screenshots?

Lets change the icon in a separate issue, because it is a little bit tricky. The style guide does define one, so I think its best to follow that as a guidance.

Rerolled patch #20. Ready for more testing.

Issue for changing the icon here: #1974928: Update throbber icon

Rerolling this soon!

It seems official tag is FUDK (kinda weird, BTW)

Rerolled. Was only one conflict in core/modules/quickedit/css/quickedit.icons.css

+++ b/core/themes/seven/css/style.css
@@ -918,6 +918,19 @@ textarea.form-textarea {
+input.form-autocomplete.is-loading,
+input.form-text.is-loading,
+input.form-tel.is-loading,
+input.form-email.is-loading,
+input.form-url.is-loading,
+input.form-search.is-loading,
+input.form-number.is-loading,
+input.form-color.is-loading,
+input.form-file.is-loading,
+textarea.form-textarea.is-loading,
+select.form-select.is-loading {

Is there any input that this will not work on? Maybe a input:not() would be easier to maintain?

+++ b/core/misc/ajax.js
@@ -461,11 +461,10 @@
     else if (this.progress.type === 'throbber') {

@@ -478,9 +477,7 @@
-    if (this.progress.element) {
-      $(this.progress.element).remove();
-    }
+    $(this.element).removeClass('is-loading');

Shouldn't add a condition to avoid the code execution on all ajax calls, eg:

if (this.progress.type === 'throbber')
...
..

Rerolled the Patch manually.

I tried to mimic the way the progress bar is set up, by adding a Throbber Class in progress.js and creating the instances in ajax.js.

I also consolidated the css from this patch with other css that has been added since this issue started.

I think the next step would be nice to replace throbber-active.gif with a css3 animated .svg, similar to what autocomplete has.

good idea but i think we should rewritten the function into Mixin pattern. (more re-usable & less duplicated code)

@LewisNyman,

Sorry, i'm not speaking clearly. It's programming side designs pattern. Not the CSS Preprocessor function. :)

So now there is a movement to introduce HiDPI-compliant SVG files across core, which presents problems with the purely class-based background image rotation technique.
Simply put, the only way to animate/rotate SVG elements is using CSS transitions (like how progress bar currently works). But with a purely class-based solution, we cannot get a rotating throbber when used as a background image inside autocomplete form elements. We really need a standard DOM based solution (much like progress bar) that adds the appropriate DOM elements after the item in question.

I think we should re-open #2181399: Consider moving the animated .GIF throbber outside the autocomplete fields and using CSS animation instead. and focus on getting one single standardized way to add this throbber to the page that fully supports the hi-res/scalable SVG image animation.

Finally, the ideas proposed in #2407859: Allow theming throbber element could solve a lot of the original issues with the throbber being completely inaccessible to themers. I think there might be some useful code on the last patch here that could combine forces with that issue to provide themable throbbers.

Tagging because this is semi-related and affected by HiDPI (see prev comment).

Edit: remove double comment posted.

I came across this issue regarding theming the ajax throbber, looks like it has came to a halt (nothing for 3 years), but I found this Ajax Loader contrib module that I think solves the issue for themers. As a developer inspecting the code it's provides an example of what you could do if you need something more custom.

Is this still a problem after #2407859: Allow theming throbber element has been solved?

Hi @lauriii – I think this could still be an issue I think, or maybe a spin off issue? Although now we're less likely to use CSS pseudo content to add markup/spinners etc (because of #2407859), people might still want to use a general 'is-loading' CSS class on the body to do things like disable a button when an AJAX event is going on.

From the original issue description

A button could change text or animate. I would also like to add a class to to the body of the page during loading, this would make full screen loading animations easier, a very common UI pattern.

A .is-loading or similar class would mean we could do something like the below to discourage users from clicking a button twice while an AJAX event is still pending.

.is-loading .my-fancy-button {
  filter: grayscale(100%);
  pointer-events: none;
  opacity: 0.8;
  background-image: url(spinner.gif);
  background-repeat: no-repeat;
  background-position: left;
}

+1, a class would be *very* useful in many cases I've experienced. I also think the class should not only be added to the body but also to the respective view, because there might be multiple views on the page and you might want to selectively show loading animations etc. This would make it possible, for example, to easily gray out the corresponding exposed form while the AJAX view is loading etc. Stuff like that is currently really hard to do because you are only left with that fixed element which is inserted at a fixed position and which you might not even want there.

I'm currently working around that by directly listening for jQuery's ajaxBefore/ajaxComplete events, trying to detect when a view is loading etc. It's really complicated, because ajaxBefore/ajaxComplete events are triggered by *ANY* ajax happening on the page. A simple class that is automatically added to the view container would make all this infinitely simpler.