Closed Bug 872397 Opened 12 years ago Closed 4 years ago

moving by words having @ char is inconsistent

Categories

(Core :: Disability Access APIs, defect)

Product:
Core
Component:
Disability Access APIs
Platform:
All
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
83 Branch
Tracking Flags:
Tracking Status
firefox83 --- verified

People

(Reporter: surkov, Assigned: Jamie)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(2 files)

Move behaviour across browsers and OSs.
(deleted), text/plain
Details
Bug 872397: Work around inconsistencies in layout word movement to ensure that a11y word start boundaries are consistent around punctuation and white space.
(deleted), text/x-phabricator-request
Details
on Windows when you navigate "@private" by words then moving right takes no stops, moving left takes two stops (after @ and before @). On Mac behavior is consistent, @ is skipped. Trev, you mentioned sometime ago then you'd join text work. It'd be good if you take a look at this layout bug.
hellp@private IE 9 (win7): stops before and after @ Chrome 25 (win 7): stop after @ Firefox 22 (win 7): stop after @ on OS X @ is a part of word, no stops in Chrome, Safari, Firefox @private: IE, Firefox: stop after @ for left-to-right, no stops for right-to-left Chrome: stop after @ always private@ Chrome, Firefox: no stops IE: stop before @ It seems it'd be ok if @ was treated as word break character (a Chrome behavior). Sounds ok?
Technically Firefox already treats @ as a word break character (example is "hello@private") so handling "@private" in different way looks as a bug. Robert, who can confirm that?
Flags: needinfo?(roc)
I don't know. I don't think it matters. Just make the change.
Flags: needinfo?(roc)
Assignee: nobody → yura.zenevich
Jonathan if Yura doesn't mind then you could take a look at this one
Don't mind at all, unassigning.
Assignee: yura.zenevich → nobody
I took a look at the state machine for PeekOffset and its helper functions. It appears that the rules in the state machine are currently set so that the caret stops after punctuation in the order of the displayed content (in function BreakWordBetweenPunctuation). I also checked what Chrome does, and it appears that punctuation is treated as if it was a whitespace character for the purpose of navigation. Using test phrases like the above as well as replacing the '@' symbol with a space and some other Unicode characters in the Po category all resulted in the same behaviour. There was an exception in the apostrophe ('), where it was treated as part of the word if surrounded by non-punctuation characters. If we wanted the behaviour for moving between words containing the '@' symbol to change, would it just be an exception to the '@' case, or for all punctuation?
I wonder if Ehsan has an opinion on comment 7?
Flags: needinfo?(ehsan)
This behavior is controlled by the layout.word_select.stop_at_punctuation and layout.word_select.eat_space_to_next_word prefs. The value of the latter pref is different on Windows and Mac (true and false, respectively.) AFAIK the reason behind this difference is native platform consistency. Does that describe comment 0?
Flags: needinfo?(ehsan)
I see the setting, but at least in my own testing, it didn't appear to be the case. The attached text document contains the behaviour that I've noticed when checking this. The move behaviour was consistent within each engine across platforms.
(In reply to comment #10) > Created attachment 8359223 [details] > --> https://bugzilla.mozilla.org/attachment.cgi?id=8359223&action=edit > Move behaviour across browsers and OSs. > > I see the setting, but at least in my own testing, it didn't appear to be the > case. The attached text document contains the behaviour that I've noticed when > checking this. The move behaviour was consistent within each engine across > platforms. OK, so can you please describe what problem you're trying to solve here? I'm confused. (I'm pretty sure that our Mac and Windows behavior is not the same here.)
originally I need to solve pure a11y problem on Windows: we get words in a11y by moving one word forward/one word backward so if these actions may return different word offsets, a11y gets confused. Thus before approaching to solve the a11y problem we'd need to figure out what is correct behavior.
(In reply to comment #12) > originally I need to solve pure a11y problem on Windows: we get words in a11y > by moving one word forward/one word backward so if these actions may return > different word offsets, a11y gets confused. Thus before approaching to solve > the a11y problem we'd need to figure out what is correct behavior. Well, this code is also responsible for regular caret navigation, and it seems like if we have different requirements on how these two things should work, then we should make the accessibility code not use the exact same code paths and prefs as the caret navigation code.
(In reply to :Ehsan Akhgari (needinfo? me!) from comment #13) > (In reply to comment #12) > > originally I need to solve pure a11y problem on Windows: we get words in a11y > > by moving one word forward/one word backward so if these actions may return > > different word offsets, a11y gets confused. Thus before approaching to solve > > the a11y problem we'd need to figure out what is correct behavior. > > Well, this code is also responsible for regular caret navigation, and it > seems like if we have different requirements on how these two things should > work, then we should make the accessibility code not use the exact same code > paths and prefs as the caret navigation code. in accessibility the word is a word defining by platform so it's likely we will need to share the code, perhaps we need to have different algorithm of word detection on a11y side. Anyway before doing any change on a11y side I would like to figure out if described inconsistency is really wanted platform behavior or not. So that I observe slightly different behavior between IE and Windows Explorer in Windows 8 so I'm curious what is criteria for platform behavior we need to mimic?
(In reply to comment #14) > (In reply to :Ehsan Akhgari (needinfo? me!) from comment #13) > > (In reply to comment #12) > > > originally I need to solve pure a11y problem on Windows: we get words in a11y > > > by moving one word forward/one word backward so if these actions may return > > > different word offsets, a11y gets confused. Thus before approaching to solve > > > the a11y problem we'd need to figure out what is correct behavior. > > > > Well, this code is also responsible for regular caret navigation, and it > > seems like if we have different requirements on how these two things should > > work, then we should make the accessibility code not use the exact same code > > paths and prefs as the caret navigation code. > > in accessibility the word is a word defining by platform so it's likely we will > need to share the code, perhaps we need to have different algorithm of word > detection on a11y side. Anyway before doing any change on a11y side I would > like to figure out if described inconsistency is really wanted platform > behavior or not. So that I observe slightly different behavior between IE and > Windows Explorer in Windows 8 so I'm curious what is criteria for platform > behavior we need to mimic? I'd test a native application such as Notepad. Also note that the behavior may have changed on Windows 8. The code in question probably predates Windows XP even. ;-)

As I see it, the problem isn't really whether we treat punctuation as a separate stop or not. The problem is that when layout.word_select.stop_at_punctuation is true (as it is by default), the behaviour for next word and previous word is asymmetric. STR:

  1. Set layout.word_select.stop_at_punctuation to true if it isn't already.
  2. Open this test case:
    data:text/html,<input type="text" value="@a">
  3. Focus the text field.
  4. Move to the start of the line.
  5. Select next word with the keyboard (shift+control+rightArrow on Windows).
    • Observe: "@a" is selected.
  6. Unselect previous word with the keyboard (shift+control+leftArrow on Windows).
    • Expected: "@a" should be unselected.
    • Actual: "a" is unselected, leaving "@" selected.

I can't reproduce this in any other Windows editor (Notepad, Wordpad, Chrome), nor can I see any benefit to this asymmetry. Whether we stop on punctuation or not, I would think it should be symmetric.

Note that things are symmetric if that pref is false.

Ehsan, do you know if this asymmetry is intentional?

Flags: needinfo?(ehsan)
Assignee: nobody → jteh
Pushed by mzehe@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/34e52092bb57 Work around inconsistencies in layout word movement to ensure that a11y word start boundaries are consistent around punctuation and white space. r=MarcoZ

https://hg.mozilla.org/mozilla-central/rev/34e52092bb57

Status: NEW → RESOLVED
Closed: 4 years ago
status-firefox83: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → 83 Branch
QA Whiteboard: [qa-83b-p2]
Component: Layout → Disability Access APIs
Flags: needinfo?(ehsan)

I was unable to reproduce the initial issue using an old Nightly build using the STR from comment 16 I get the actual result (step 6) on old Nightly before the fix and also in latest Nightly and Beta 83. Are those the correct steps to reproduce/verify this bug or maybe I'm missing something?

Flags: needinfo?(jteh)

Sorry, the actual user impact wasn't clearly explained in this bug.

STR (with the NVDA screen reader):

  1. Ensure NVDA's punctuation/symbol level is set to all: NVDA menu -> Preferences -> Settings -> Speech -> Punctuation/symbol level: all.
  2. Open this URL:
    data:text/html,before<input type="text" value="a ! @b$">
  3. Tab to the text box.
  4. Press home to move to the start of the line.
  5. Press control+rightArrow.
    • Expected: NVDA says "bang"
    • Actual: NVDA says "a bang"
  6. Press control+rightArrow.
    • Expected: NVDA says "at b dollar"
    • Actual: NVDA says "at"
Flags: needinfo?(jteh)

(In reply to James Teh [:Jamie] from comment #21)

Sorry, the actual user impact wasn't clearly explained in this bug.

STR (with the NVDA screen reader):

  1. Ensure NVDA's punctuation/symbol level is set to all: NVDA menu -> Preferences -> Settings -> Speech -> Punctuation/symbol level: all.
  2. Open this URL:
    data:text/html,before<input type="text" value="a ! @b$">
  3. Tab to the text box.
  4. Press home to move to the start of the line.
  5. Press control+rightArrow.
    • Expected: NVDA says "bang"
    • Actual: NVDA says "a bang"
  6. Press control+rightArrow.
    • Expected: NVDA says "at b dollar"
    • Actual: NVDA says "at"

Thanks for the steps James, I was able to reproduce on old Nightly build before the fix (2020-09-22), and verify that this is fixed in Firefox 83.0 RC using Windows 10 64bit and Windows 7 64bit.

Status: RESOLVED → VERIFIED
QA Whiteboard: [qa-83b-p2]
status-firefox83: fixed → verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: