873358 - textarea claims bogus trailing \n (HTML br)

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[alexander :surkov (:asurkov)]

Textarea container trailing <br> element when it has not empty value lie
<textarea>h</textarea>

See bug 503838.

We just create an accessible for that br which is mapped to '\n'.

That br node is not nsGkAtoms::mozeditorbogusnode, it is  nsGkAtoms::mozdirty="" node.

Comment 1

[alexander :surkov (:asurkov)]

note, there's related bug 240933 (which seems removed all brs but the trailing one).

Comment 2

[(no longer active)]

Not sure what you're asking for here, Alexander.

Comment 3

[alexander :surkov (:asurkov)]

if I have <textarea>hello</textarea> then DOM looks the following way (judging by accessibility tree):

textarea
  textleaf (hello)
  br

that br is confusing for accessibility. Why it wasn't removed in bug 240933 and is there a reason to have it nowdays?

Comment 4

[(no longer active)]

(In reply to comment #3)
> if I have <textarea>hello</textarea> then DOM looks the following way (judging
> by accessibility tree):
> 
> textarea
>   textleaf (hello)
>   br
> 
> that br is confusing for accessibility. Why it wasn't removed in bug 240933 and
> is there a reason to have it nowdays?

Because it's needed for caret positioning.  Of course we can fix that, but we don't have anybody to do that work!  Until that happens, accessibility should ignore that node.

Comment 5

[alexander :surkov (:asurkov)]

so at accessibility layer we can just ignore any non text nodes under textarea. Is that correct?

Comment 6

[(no longer active)]

(In reply to comment #5)
> so at accessibility layer we can just ignore any non text nodes under textarea.
> Is that correct?

This should be the only non-textnode node under textarea's anonymous div, so, yes.  Although if you want to be super conservative, you could choose to only ignore trailing BRs.

Comment 7

[alexander :surkov (:asurkov)]

Should I leave this bug open for layout part and get another one for accessibility fix?

Comment 8

[(no longer active)]

(In reply to comment #7)
> Should I leave this bug open for layout part and get another one for
> accessibility fix?

No, we have bug 503838 on the higher level problem.

Comment 9

[alexander :surkov (:asurkov)]

Attachment: patch

Comment 10

[Trevor Saunders (:tbsaunde)]

do you understand regressions and have plan to work on them?

Comment 11

[alexander :surkov (:asurkov)]

(In reply to Trevor Saunders (:tbsaunde) from comment #10)
> do you understand regressions

I don't but as long as new move by words logic still works with the change then I don't worry about move by lines regressions

> and have plan to work on them?

yes

Comment 12

[Trevor Saunders (:tbsaunde)]

(In reply to alexander :surkov from comment #11)
> (In reply to Trevor Saunders (:tbsaunde) from comment #10)
> > do you understand regressions
> 
> I don't but as long as new move by words logic still works with the change
> then I don't worry about move by lines regressions


ok

Comment 13

[alexander :surkov (:asurkov)]

Btw, I was reported that JAWS misses textareas in vb in Aurora (Firefox 23) because it started to expose child text leaf accessibles and that was caused by bug 865997. Bug 865997 logic is expose everything as long as non textual children are presented. In this bug we prevent HTML br to appear inside textareas so this bug will be a fix for JAWS issue. We need to backport it Aurora.

Comment 14

[alexander :surkov (:asurkov)]

http://hg.mozilla.org/integration/mozilla-inbound/rev/7ec8a1e24dd6

Comment 15

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/7ec8a1e24dd6

Comment 16

[Marco Zehe (:MarcoZ)]

Note that this caused bug 875794. I will not approve a backport to 23 unless that bug is resolved and a fix tested. The alternative is to back out this bug and have FS find another solution to detecting textareas properly.