795785 - editor isn't scrolled to the caret position if editor specified overflow: hidden;

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

reported via fxinput: http://input.mozilla.org/opinion/3236299

The editor of twitter is specified overflow: hidden;. Then, when we input longer text then the editor, the overflowed text is clipped. This happens a lot of times with Japanese language because the average character width is wider than Western languages and composition string is longer than its final result.

So, I think that editor should scroll to the caret position after something is inputted even if the overflow is hidden.

dbaron, do you have objection about the behavior for overflow: hidden;?

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

FYI: IE, Chrome, Safari and Opera scrolls to caret after editing the editor in twitter.

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Patch

This patch just ensures that editor always do "selection into view" after editing. If users just move the caret, scroll doesn't occur. I'm looking the code about it, but I think that it should be done in another bug.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

What feedback did you want from me?

Comment 4

[(no longer active)]

Comment on attachment 666449 [details] [diff] [review]
Patch

Review of attachment 666449 [details] [diff] [review]:
-----------------------------------------------------------------

r=me, but if we do this, we also need to scroll when moving the caret using the keyboard.

Also, what happens if the user tries to scroll by making a selection and try to extend it past the bounds of the editable area?

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to David Baron [:dbaron] from comment #3)
> What feedback did you want from me?

About the last line of comment #0.

IIRC, you said that scrollable elements which are specified overflow: hidden; shouldn't be scrollable by user input such as mouse wheel or keyboard. So, if you think that we shouldn't fix this bug with my approach, we need to contact twitter.com.

However, in all other browsers, we can scroll the editor content by either caret move or text input. Therefore, I don't think we should keep our behavior in editors.

So, I want to know your thought about this issue.

(In reply to Ehsan Akhgari [:ehsan] from comment #4)
> r=me, but if we do this, we also need to scroll when moving the caret using
> the keyboard.

Thank you for your review. Yeah, I think so. But I'm not sure whether we should scroll overflow: hidden; contents in the caret browsing mode too. Therefore, I'd like to discuss about this issue in another bug.

> Also, what happens if the user tries to scroll by making a selection and try
> to extend it past the bounds of the editable area?

Nothing changed by this patch. The expanding selection by keyboard doesn't cause scroll in such editor. However, when I press up key at first line or down key at last line, it causes scrolling. I'm not sure the reason.

Comment 6

[(no longer active)]

(In reply to comment #5)
> (In reply to David Baron [:dbaron] from comment #3)
> > What feedback did you want from me?
> 
> About the last line of comment #0.
> 
> IIRC, you said that scrollable elements which are specified overflow: hidden;
> shouldn't be scrollable by user input such as mouse wheel or keyboard. So, if
> you think that we shouldn't fix this bug with my approach, we need to contact
> twitter.com.
> 
> However, in all other browsers, we can scroll the editor content by either
> caret move or text input. Therefore, I don't think we should keep our behavior
> in editors.
> 
> So, I want to know your thought about this issue.
> 
> (In reply to Ehsan Akhgari [:ehsan] from comment #4)
> > r=me, but if we do this, we also need to scroll when moving the caret using
> > the keyboard.
> 
> Thank you for your review. Yeah, I think so. But I'm not sure whether we should
> scroll overflow: hidden; contents in the caret browsing mode too. Therefore,
> I'd like to discuss about this issue in another bug.
> 
> > Also, what happens if the user tries to scroll by making a selection and try
> > to extend it past the bounds of the editable area?
> 
> Nothing changed by this patch. The expanding selection by keyboard doesn't
> cause scroll in such editor. However, when I press up key at first line or down
> key at last line, it causes scrolling. I'm not sure the reason.

That sucks, please file a follow-up to investigate this.  Thanks!

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

So what happens if you type something to a overflow:hidden editor so that the content is scrolled.
Then you move cursor to the start of the text (so that the overflown are is hidden).
How can you see the end of the text you just typed?

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Olli Pettay [:smaug] from comment #7)
> So what happens if you type something to a overflow:hidden editor so that
> the content is scrolled.

Editor is not scrolled with current build. The patch makes editor scrolled to the end of inserted text because the caret is always moved to there.

> Then you move cursor to the start of the text (so that the overflown are is
> hidden).

Nothing happens even with the patch. I need more work for it in another bug. See the end of comment 5 for the detail.

> How can you see the end of the text you just typed?

The patch makes it shown into the view automatically. I think that this patch helps twitter users in most cases.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

But does this really help? After you have stopped typing, you can't actually see the whole
text.

Comment 10

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Olli Pettay [:smaug] from comment #9)
> But does this really help? After you have stopped typing, you can't actually
> see the whole
> text.

Yes. For example, composition string of IME is usually longer than the final (committed) text. When I type Hiragana characters, it sometimes overflows from the editor of twitter.com. Then, I cannot see whether the *inputting* text is typed as expected until converting, committing and press down key. But I can confirm the inputting text with the patched build. I feel it really helps users to type Japanese text.

Comment 11

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

So, I mean that during IME composition, users never see the overflown composition text. There is no way to access it.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

But after typing, can you scroll the text? If not, some of it is hidden and you can't check
what you actually typed.

Comment 13

[Olli Pettay [:smaug][[e-mail]]]

I'm a bit worried that it is easier to type long text, but after typing it is not
possible to see it all.

Comment 14

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Olli Pettay [:smaug] from comment #12)
> But after typing, can you scroll the text? If not, some of it is hidden and
> you can't check
> what you actually typed.

It's true in some situations. However, I don't see such overflow: hidden; editor except twitter.com (in Facebook, the editor looks like overflow: hidden; but the editor will be expanded when I type long text). So, I want to help users in twitter actually. From this viewpoint, the editor can show 4 lines. The enough space doesn't cause what you worry about.

Comment 15

[(no longer active)]

(In reply to comment #14)
> (In reply to Olli Pettay [:smaug] from comment #12)
> > But after typing, can you scroll the text? If not, some of it is hidden and
> > you can't check
> > what you actually typed.
> 
> It's true in some situations. However, I don't see such overflow: hidden;
> editor except twitter.com (in Facebook, the editor looks like overflow: hidden;
> but the editor will be expanded when I type long text). So, I want to help
> users in twitter actually. From this viewpoint, the editor can show 4 lines.
> The enough space doesn't cause what you worry about.

Well I agree that your patch improves things, but if we wanna do that then we should also fix scrolling in other cases, which pretty much amounts to ignoring overflow:hidden on text controls altogether.

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Okay, I wrote a patch for caret move...
https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=8b7066563a23

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.2 Scroll editor when caret is moved even if it's specified overflow: hidden;

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

The second patch makes editable editors scrollable by caret move. This might not be good enough, but I think that this temporarily improves the a11y.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

smaug:

Now, the second patch makes caret move cause scrolling, would your review the both patches?

dbaron:

I'd like to confirm your idea. Do you have any objection for scrolling the overflow:hidden; editors even though current behavior actually causes a11y issue in twitter.com? So, I mean that should this be an evangelism bug?

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

This is not an our regression but twitter has changed the editor behavior. It used to resize the editor for long text, but now, the size is fixed. This is major problem in very famous website and other browsers don't have this problem. So, I think that we should take care as far as possible.

Comment 22

[Olli Pettay [:smaug][[e-mail]]]

This all is risky.

Would it be hard to limit the behavior to <input> and <textarea> and would that fix twitter case?
Also, how do other browsers handle contentEditable with overflow:hidden?

Comment 23

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Olli Pettay [:smaug] from comment #22)
> This all is risky.

Yeah, unfortunately.

> Would it be hard to limit the behavior to <input> and <textarea> and would
> that fix twitter case?

It's possible. The risk of part.1 isn't so changed. But the part.2 patch (this is risky) can be replaced with another patch which fixes this bug in nsEditorCommands.cpp.

> Also, how do other browsers handle contentEditable with overflow:hidden?

IE, Safari and Chrome work same as <textarea>. Caret move in Opera doesn't work fine, though.

Comment 24

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #23)
> (In reply to Olli Pettay [:smaug] from comment #22)
> > Would it be hard to limit the behavior to <input> and <textarea> and would
> > that fix twitter case?
> 
> It's possible. The risk of part.1 isn't so changed. But the part.2 patch
> (this is risky) can be replaced with another patch which fixes this bug in
> nsEditorCommands.cpp.

So, I think that if we could fix this bug on Aurora, only changing part.2 is the safest way.

Comment 25

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.2 alternative (only change the behavior in <input> and <textarea>)

This is the alternate patch for Aurora.

Comment 26

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.1 Editor should scroll the selection into view after edit even when the editor is specified overflow: hidden;

# fix a mistake in the test (not dispatched "compositionend" event).

Comment 27

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.2 Scroll editor when caret is moved even if it's specified overflow: hidden;

I'll land them to m-i tomorrow.

Comment 28

[Olli Pettay [:smaug][[e-mail]]]

Isn't the next merge tomorrow. But perhaps if you land the patches early in your time, that is ok.

Comment 29

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Okay, I got a chance to land them.
https://hg.mozilla.org/integration/mozilla-inbound/rev/3d8d4f10eb62
https://hg.mozilla.org/integration/mozilla-inbound/rev/0c48cbf5e4c5

Comment 30

[Phil Ringnalda (:philor)]

https://hg.mozilla.org/mozilla-central/rev/3d8d4f10eb62
https://hg.mozilla.org/mozilla-central/rev/0c48cbf5e4c5

Comment 31

[Alex Keybl [:akeybl]]

What can't the user do when the caret position is incorrectly placed? Sorry, we're not fully understanding the impact here. Unclear if this is minor or critical.

Comment 32

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Alex Keybl [:akeybl] from comment #31)
> What can't the user do when the caret position is incorrectly placed?

If the caret is placed outside of the visible rectangular of the editor, user cannot confirm what he/she typed actually. See the video attached to Bug 797332.
https://bugzilla.mozilla.org/attachment.cgi?id=667455

This is more serious bug for CJK users. Chinese, Japanese and Korean characters are wider than Western alphabets. So, the editor of twitter.com cannot show 140 CJK characters without scroll (only about 70 CJK characters can be contained in the editor rectangular). Additionally, Japanese users need to use Japanese IME. Users input Kana characters which indicate pronunciation first, an then convert to Chines characters which indicate meaning of the words. So Japanese users cannot check the result of IME conversion if the text is overflown from the editor rectangular.

> Sorry,
> we're not fully understanding the impact here. Unclear if this is minor or
> critical.

Sorry for the not enough explanation. If we can fix this bug in other branches, we can lower risk patch for the part.2 patch. Unfortunately, a part of the changed code is shared with non-editor such as caret browsing mode. So, the part.2 patch is pretty risky for Aurora and Beta.

The alternative patch for part.2 affects only editors for <input> and <textarea>. So, not fixes same issue of HTML editor. However, it's enough for current purpose, i.e., for fixing the twitter.com issue.

Comment 33

[Lukas Blakk [:lsblakk] use ?needinfo]

Go ahead and nominate for uplift, tracking for Beta/Aurora.

Comment 34

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 668913 [details] [diff] [review]
part.2 alternative (only change the behavior in <input> and <textarea>)

Then, we should take this to beta (17).

Comment 35

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 668913 [details] [diff] [review]
part.2 alternative (only change the behavior in <input> and <textarea>)


>-function doEnterKeyTest(aElement, aElementDescription, aCallback)
>+function doEnterKeyAndArrowKeyTest(aElement, aElementDescription, aDoTestCursorMove, aCallback)
> {
>   aElement.focus();
>   aElement.scrollTop = 0;
>   hitEventLoop(function () {
>     is(aElement.scrollTop, 0,
>        aElementDescription + "'s scrollTop isn't 0");
>     synthesizeKey("VK_RETURN", { });
>     synthesizeKey("VK_RETURN", { });
>     synthesizeKey("VK_RETURN", { });
>     synthesizeKey("VK_RETURN", { });
>     synthesizeKey("VK_RETURN", { });
>     synthesizeKey("VK_RETURN", { });
>     hitEventLoop(function () {
>       isnot(aElement.scrollTop, 0,
>             aElementDescription + " was not scrolled by inserting line breaks");
>-      aCallback();
>+      if (!aDoTestCursorMove) {
>+        aCallback();
>+        return;
>+      }
>+      var scrollTop = aElement.scrollTop;
>+      synthesizeKey("VK_UP", { });
>+      synthesizeKey("VK_UP", { });
>+      synthesizeKey("VK_UP", { });
>+      synthesizeKey("VK_UP", { });
>+      synthesizeKey("VK_UP", { });
>+      hitEventLoop(function () {
>+        isnot(aElement.scrollTop, scrollTop,
>+              aElementDescription + " was not scrolled by up key events");
>+        synthesizeKey("VK_DOWN", { });
>+        synthesizeKey("VK_DOWN", { });
>+        synthesizeKey("VK_DOWN", { });
>+        synthesizeKey("VK_DOWN", { });
>+        synthesizeKey("VK_DOWN", { });
>+        hitEventLoop(function () {
>+          is(aElement.scrollTop, scrollTop,
>+             aElementDescription + " was not scrolled by down key events");
>+          aCallback();
>+        }, 20);
>+      }, 20);
>     }, 20);
>   }, 20);
> }


Don't we need also VK_LEFT/RIGHT tests?

Comment 36

[(no longer active)]

Comment on attachment 668913 [details] [diff] [review]
part.2 alternative (only change the behavior in <input> and <textarea>)

Review of attachment 668913 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with the added VK_LEFT/VK_RIGHT tests.

Comment 37

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Olli Pettay [:smaug] from comment #35)
> Comment on attachment 668913 [details] [diff] [review]
> part.2 alternative (only change the behavior in <input> and <textarea>)

> Don't we need also VK_LEFT/RIGHT tests?

(In reply to Ehsan Akhgari [:ehsan] from comment #36)

> r=me with the added VK_LEFT/VK_RIGHT tests.

Did you mean the |word-wrap: normal;| case? Currently, our <textarea> has |word-wrap: break-word;| in the UA style, though.

Comment 38

[(no longer active)]

(In reply to comment #37)
> (In reply to Olli Pettay [:smaug] from comment #35)
> > Comment on attachment 668913 [details] [diff] [review]
> > part.2 alternative (only change the behavior in <input> and <textarea>)
> 
> > Don't we need also VK_LEFT/RIGHT tests?
> 
> (In reply to Ehsan Akhgari [:ehsan] from comment #36)
> 
> > r=me with the added VK_LEFT/VK_RIGHT tests.
> 
> Did you mean the |word-wrap: normal;| case? Currently, our <textarea> has
> |word-wrap: break-word;| in the UA style, though.

Why does that make a difference?

Comment 39

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

> Why does that make a difference?

<textarea> is probably never overflown along horizon with default style. <div contenteditable> is overflown, though.

Comment 40

[Olli Pettay [:smaug][[e-mail]]]

What about <input> ?

Comment 41

[(no longer active)]

(In reply to comment #39)
> > Why does that make a difference?
> 
> <textarea> is probably never overflown along horizon with default style. <div
> contenteditable> is overflown, though.

You could also test that with an input element.

Comment 42

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Er, I didn't mean that it's hard to test with <textarea>. I just did confirm that.

Anyway, it should be tested on trunk too, I'll add another patch for the tests.

Comment 43

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.3 Add horizontal scroll tests (for m-c)

Comment 44

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: part.3 Add horizontal scroll tests (for beta)

the difference form the previous patch is whether the doKeyEventTest() has additional argument or not. The change is completely same as the previous patch.

Comment 45

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/10937fecf663

Comment 46

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 668917 [details] [diff] [review]
part.1 Editor should scroll the selection into view after edit even when the editor is specified overflow: hidden;

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
Caused by twitter.com side, not our bug but it's too famous web service which we have this problem.

User impact if declined: 
Users cannot see the inputted text which is overflown from the editor due to not to scroll the caret position automatically. CJK text can input only 70 characters in the editor of twitter.com. I see a lot of complain in fxinput and Army of Awesome from Japanese users.

Testing completed (on m-c, etc.):
The patches were landed on m-c a week ago.

Risk to taking this patch (and alternatives if risky):
If there were some bugs, users could scroll <div> elements which are specified overflow: hidden;. But probably users don't complain such regressions. Probably web designers do.

String or UUID changes made by this patch: 
UUID isn't changed but adding a const to nsISelectionController for a new option for scrollSelectionIntoView(). New flag must be safe. I don't think addon developers use 0xFFFFFFFF to the argument.

Comment 47

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 668913 [details] [diff] [review]
part.2 alternative (only change the behavior in <input> and <textarea>)

[Approval Request Comment]
Bug caused by (feature/regressing bug #):
See above comment.

User impact if declined: 
Users cannot scroll overflow:hidden; editor by arrow keys (i.e., moving caret doesn't cause scrolling the editor in twitter.com).

Testing completed (on m-c, etc.): 
Never. This is made only for beta for lower risk than the part.2 for m-c. If we took the patch for m-c, it could cause some regressions without editors. But this patch make editors scroll only when <input> or <textarea> receives caret moving commands.

Risk to taking this patch (and alternatives if risky):
I have no idea for the regressions which this patch would cause.

String or UUID changes made by this patch: 
Nothing.

Comment 48

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Comment on attachment 670700 [details] [diff] [review]
part.3 Add horizontal scroll tests (for beta)

[Approval Request Comment]
Testing completed (on m-c, etc.): 
Today, this was landed to m-i.

Risk to taking this patch (and alternatives if risky): 
Nothing. This just adds a test for part.2.

String or UUID changes made by this patch:
Nothing. Only changes the new test.

Comment 49

[Olli Pettay [:smaug][[e-mail]]]

So have we contacted twitter about the change?

Comment 50

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Olli Pettay [:smaug] from comment #49)
> So have we contacted twitter about the change?

*I* have never tried it. I don't have any idea to fix the issue on the twitter side, though. They have stopped expanding the editor for the contents. That caused this bug. I don't know the reason but it's difficult to think they will revert the change because it probably has some merit.

Comment 51

[Olli Pettay [:smaug][[e-mail]]]

Web sites do revert changes if they break functionality.
We need to evangelize here.

Could you file a new evangelism bug. We should figure out who to contact @twitter and whether they
could fix this issue on their side.

Comment 52

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Olli Pettay [:smaug] from comment #51)
> Web sites do revert changes if they break functionality.
> We need to evangelize here.
> 
> Could you file a new evangelism bug. We should figure out who to contact
> @twitter and whether they
> could fix this issue on their side.

filed bug 801526.

Comment 53

[Alex Keybl [:akeybl]]

(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #47)
> Risk to taking this patch (and alternatives if risky):
> I have no idea for the regressions which this patch would cause.

We can't take a patch with unknown risk. What's the worst case scenario here Masayuki/Ehsan?

Comment 54

[(no longer active)]

I would recommend against taking this patch on beta.  This is not small and definitely not risk free and I don't see why the risk here would be acceptable to beta.

Comment 55

[Lukas Blakk [:lsblakk] use ?needinfo]

Comment on attachment 668917 [details] [diff] [review]
part.1 Editor should scroll the selection into view after edit even when the editor is specified overflow: hidden;

oops - just caught up - taking it back.

Comment 56

[Lukas Blakk [:lsblakk] use ?needinfo]

Wontfixing for Beta based on Ehsan's risk assessment, sounds like we can wait for 18 to come with the fix.

Comment 57

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Alex Keybl [:akeybl] from comment #53)
> (In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #47)
> > Risk to taking this patch (and alternatives if risky):
> > I have no idea for the regressions which this patch would cause.
> 
> We can't take a patch with unknown risk. What's the worst case scenario here
> Masayuki/Ehsan?

Hmm, I meant that "I have no idea of possible regressions because of very simple change".

(In reply to Ehsan Akhgari [:ehsan] from comment #54)
> I would recommend against taking this patch on beta.  This is not small and
> definitely not risk free and I don't see why the risk here would be
> acceptable to beta.

Oh, I'd like you to take objection to it at requesting tracking beta...

Comment 58

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/10937fecf663

Comment 59

[(no longer active)]

(In reply to comment #57)
> (In reply to Ehsan Akhgari [:ehsan] from comment #54)
> > I would recommend against taking this patch on beta.  This is not small and
> > definitely not risk free and I don't see why the risk here would be
> > acceptable to beta.
> 
> Oh, I'd like you to take objection to it at requesting tracking beta...

I would also like this to get fixed on beta very much, but I am not comfortable with the risk of the existing patch on beta (and unfortunately I can't think of a simpler solution either.)  :(

Comment 60

[Virgil Dicu [:virgil] [QA]]

Mozilla/5.0 (X11; Linux i686; rv:18.0) Gecko/20100101 Firefox/18.0

Verified in 18 beta 3 - Ubuntu 12.04, Mac OS 10.8, Windows 7.

Could reproduce the initial problem with twitter's input box in 17. Could no longer reproduce in 18b3. Scrolling, typing, focus -all looks good. Same as Chrome in terms of behavior.

Comment 61

[Lukas Blakk [:lsblakk] use ?needinfo]

Sadly we didn't get this into 17 and it doesn't meet ESR criteria for security-centric dot releases. If a number of ESR users call out this issue as seriously impacting their deployments we can revisit, but for now calling it a wontfix for both ESR.

Comment 62

[Tracy Walker [:tracy]]

mass remove verifyme requests greater than 4 months old