Bug 1830820 Comment 4 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Olli's suggestion in comment 2 sounds good to me.  We may want to have some supplemental pref-controlled delay at some level before we start accepting user input, to avoid problems where a user taps *immediately* as we paint (in the spirit of waiting until a user "can reasonably respond" per bug 1783252).  On the order of tens of milliseconds, perhaps, just to ensure users have a chance to see what they're tapping.

(The "stuff moved around on the page and I clicked the wrong thing" scenario in bug 1568934 is harder to robustly fix, without causing unwanted breakage of legitimate content. I'll add some comments there.  I'm not sure whether it's tractable to mitigate that sort of issue, and it's not obvious to me that mitigations over there would prevent security issues.  But when navigation is involved, it does seem more concerning and more tractable to fix.)
Olli's suggestion in comment 2 sounds good to me.  We may want to have some supplemental pref-controlled delay at some level before we start accepting user input, to avoid problems where a user taps *immediately* as we paint (in the spirit of waiting until a user "can reasonably respond" per bug 1783252).  On the order of tens of milliseconds, perhaps, just to ensure users have a chance to see what they're tapping.

(The "stuff moved around on the page and I clicked the wrong thing" scenario in bug 1568934 is harder to robustly fix, without causing unwanted breakage of legitimate content. I'll add some comments there [update: done, submitted bug 1568934 comment 2]. I'm not sure whether it's tractable to mitigate that sort of issue, and it's not obvious to me that mitigations over there would prevent security issues.  But when navigation is involved, it does seem more concerning and more tractable to fix.)
Olli's suggestion in comment 2 sounds good to me.  We may want to have some supplemental pref-controlled delay at some level before we start accepting user input, to avoid problems where a user taps *immediately* as we paint (in the spirit of waiting until a user "can reasonably respond" per bug 1783252).  On the order of tens of milliseconds, perhaps, just to ensure users have a chance to see what they're tapping.

(The "stuff moved around on the page and I clicked the wrong thing" scenario in bug 1568934 is harder to robustly fix, without causing unwanted breakage of legitimate content. I'll add a comment there [left as bug 1568934 comment 2]. I'm not sure whether it's tractable to mitigate that sort of issue, and it's not obvious to me that mitigations over there would prevent security issues.  But when navigation is involved, it does seem more concerning and more tractable to fix.)

Back to Bug 1830820 Comment 4