Feature request: modify yellow highlight

[Ben McGinnes]

The yellow background change and fade animation is nice enough, I suppose, if the following two conditions are true:

1. The animation always completes when edited text is submitted and the original background is restored; and
2. The end user always uses websites or CSS in which the textarea has a light coloured background with dark text.

More often than not, with the aid of alternate style sheets and extensions like Dark Reader, I will not be using dark text on white or light backgrouns; I generally have the opposite (including here on GitHub asn as I type this using this plugin — oh, how meta). This will generally match reasonably closely to my preferred Emacs theme, for reference that's this modified version of zenburn.

Unfortunately that first point also often fails to be true too, especially on pages where the text area is for status updates of some type (e.g. Twitter, Mastodon instances, etc.) and so the same textarea will be used multiple times. When that happens it is possible to end up with a forced yellow background which conceals the text just when I want to be sure that it is correct before submitting/posting it.

This is … unhelpful.

I've already tried forking the project and activating it as an unpacked extension in dev mode and changing the setting in textarea.js to always leave it as the original colour (since the animation seems to be linked to text submission itself and I don't want that to stop, I just want to see it), I also commented out the default.css .highlight bit elsewhere which was also yellow.

Okay, I grepped for every reference to yellow and disabled all of them except jquery.color.min.js and only because that seemed like a reference rather than a setting. Though I did change the default from white to black right at the end there since, more often than not, in my case black will be the default background (or it will be a very dark grey).

Didn't work, but the animation does seem a little faster now than it used to be.

Since removing it doesn't seem possible, could you at least add an option to enable specifying an alternative highlight colour?

Or, better yet, specifying a highlight colour depending on what the original background colour is?

[Alex Bennée]

It is all handled in the updateTextArea() function. I think you can
just replace the line:

$(tracker.text).css({'background-color': 'yellow'});

with your new computed background colour based on what orig is and
then let the animation run from the new point to the end. The
animation stanza is:

 window.setTimeout(function() {
     // reset the text to the original without newline
     tracker.setContent(content);
     $(tracker.text).animate({ 'backgroundColor': orig }, 2000);
 }, 100);

which just fades the colour from what we have just set
css({'background-color': 'yellow'}) to back to its original colour.

If you just want to disable it completely then comment out the two
lines. We still need to do tracker.setContent(content); after the
timeout as that is a work around for sites that don't pick up the fact
we have changed the text in the textarea.

[Alex Bennée]

@Hasimir have a look at the experimental branch I pushed. It needs a little finessing because fading black to white on normal background is overly string IMHO.

[Ben McGinnes]

Ah cool, will do.

Also after an unrelated reboot one of my changes was effective (yeah, restart shouldn't've made a difference, but shrug) then I stepped each of the changes back until I found the correct one; the first one as it happens.

That works fine in Chrome in Opera, but of course that leaves Firefox and its variants, so I'll test that branch with one or more of them. Cheers.

[Ben McGinnes]

Ooh, just had a look at the diff on that branch, it does look interesting.

What I had was simply replacing this:

$(tracker.text).css({'background-color': 'yellow'});

With this:

$(tracker.text).css({'background-color': orig});

Since that guaranteed everything would be just as visible as before, but wouldn't actually change the rest of the function and since I wasn't sure how much of it related to the animation and how much related to sending the text back to the web page I figured I'd err on the side of caution.

Admittedly, my idea of writing JS normally consists of: don't write JS, write Py3 instead and load it in Brython … but that tactic tends not to work so well for things like this. 😉

[Ben McGinnes]

Yep, that contrast detection does indeed work, though I spent more time hunting around for a system I used that's currently still locked into white background.

Still, I did find one and have now tested it with both white on black and black on white and it does indeed behave as you surmised.

I think the animation not ending or getting stuck thing, however, is a slightly separate issue and most likely a bug. I also suspect that it generally only happens on pages or sites where the page is updating in real time and has a lot of traffic, so it gets stuck with that mutation code trying to track all the changes instead of just the changes to the text areas.

Which means a real fix is unlikely to be quick, easy or in any way fun. Personally I'll cope better with it now that I realise what it's doing and what sort of sites are likely to trigger it (e.g. my home Twitter feed, or Mastodon.social with the federated timeline). My sympathies in regards to that; if a fix appears, I will cheer; but I think I'll leave pestering you about it for, well, forever. 😉

I will probably go back to using the original bg trick, but the contrast animation is worth merging to master for the inevitable other users with a penchant for dark backgrounds and editors. The only thing I'm unsure of is whether to make the two animated backgrounds something like yellow (for white or light bg as originally done) and maybe blue or one of the deeper blue-violets for the dark backgrounds to keep the thematic aspect with colours that still work. I've always been quite partial to ultramarine (#4000ff) and any excuse to use it was a good excuse.

I suppose one possible work-around for a stalled animation would be to set a key-binding which explicitly runs that background setting and is always loaded with whatever orig is in the page you're on. If the extension saves the variable for each open page or identified text area then surely it can run it manually and then just configure that the same as you would any other keybinding. That's about the least painful thing I can think of.