Open Bug 567045 Opened 15 years ago Updated 9 months ago

rollback hack from bug 452161

Categories

(Core :: Disability Access APIs, defect)

defect

Tracking

()

People

(Reporter: surkov, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(2 obsolete files)

Bug 452161 introduced a hack in nsHyperTextAccessible::HypertextOffsetToDOMRange to handle 0 offset inside an empty input. The reason of this hack the input hierarchy was (see bug 452161 comment #4): html:input html:div html:br so that HTML input hadn't accessibles inside and that resulted in insertText didn't work properly on empty inputs. Nowdays hierarchy is html:input html:div empty text node (if editor is not initialized then html:div contains two empty text nodes). this (these) text node(s) are accessible so that insertText works successfully.
Attached patch patch (obsolete) — Splinter Review
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #446436 - Flags: review?(marco.zehe)
Attachment #446436 - Flags: review?(bolterbugz)
Attachment #446436 - Flags: feedback?(ehsan)
What if the editor _is_ initialized?
(In reply to comment #2) > What if the editor _is_ initialized? I suppose the hierarchy is: html:input html:div empty text node I think the difference between initialized editor and not initialized editor is amount of empty text nodes (initialized has one text node, uninitialized has two text nodes). But that's I'd like to check with you since my observation are based on testing so I can't be 100% sure when editor is initialized when it's not. When I inspect HTML input accessible the first time then I see two text nodes, when I focused it then I see one text node.
Here's how the frame tree looks for data:text/html,<input type=text>: nsTextControlFrame@0x1639a98 {0,0,9300,1320} [state=80c04010] [content=0x17e22fb0] [overflow=-240,-240,9780,1800] [sc=0x1639798]< HTMLScroll(div)(-1)@0x1ab2ba8 next=0x1ab30e0 {180,240,8940,840} [state=00084000] [content=0x1e665290] [sc=0x1639748]< Block(div)(-1)@0x1ab2e78 [content=0x1e665290] {0,0,8940,840} [state=00d04020] sc=0x1639570(i=1,b=0) pst=:-moz-scrolled-content< line 0x1ab30b8: count=1 state=inline,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x8100] {60,0,0,840} < Text(0)@0x1ab3070[0,0,T] {60,660,0,0} [state=00404000] [content=0x1e617790] sc=0x1ab2f08 pst=:-moz-non-element< "" > > > > HTMLScroll(div)(-1)@0x1ab30e0 {180,240,8940,840} [state=00004000] [content=0xa63d30] [sc=0x1ab2a38]< Block(div)(-1)@0x1ab3310 [content=0xa63d30] {0,0,8940,840} [state=00d04020] sc=0x1ab3278(i=1,b=0) pst=:-moz-scrolled-content< line 0x1ab3460: count=1 state=inline,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x8100] {60,0,0,840} < Text(0)@0x1ab3418[0,0,T] {60,660,0,0} [state=00404000] [content=0xa2e170] sc=0x1ab33a0 pst=:-moz-non-element< "" > > > > > Here's how it looks when the editor is initialized (for example, when you click on the input box: nsTextControlFrame@0x1639a98 {0,0,9300,1320} [state=80c04010] [content=0x17e22fb0] [overflow=-240,-240,9780,1800] [sc=0x1639798]< HTMLScroll(div)(-1)@0x1ab2ba8 next=0x1ab30e0 {180,240,8940,840} [state=00084030] [content=0x1e665290] [sc=0x1639748]< Block(div)(-1)@0x1ab2e78 [content=0x1e665290] {0,0,8940,840} [state=00d04030] sc=0x1639570(i=1,b=0) pst=:-moz-scrolled-content< line 0x1ab30b8: count=1 state=inline,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:linebr[0xa100] {60,0,1,840} < Frame(br)(0)@0x18e9680 {60,0,1,840} [state=00004000] [content=0x1e617790] > > > HTMLScroll(div)(-1)@0x1ab30e0 {180,240,8940,840} [state=00004000] [content=0xa63d30] [sc=0x16349c0]< Block(div)(-1)@0x1ab3310 [content=0xa63d30] {0,0,8940,840} [state=00d04020] sc=0x1ab2f08(i=1,b=0) pst=:-moz-scrolled-content< line 0x1ab3460: count=1 state=inline,clean,prevmarginclean,not impacted,not wrapped,before:nobr,after:nobr[0x8100] {60,0,0,840} < Text(0)@0x1ab3418[0,0,T] {60,660,0,0} [state=00404000] [content=0xa2e170] sc=0x1ab3278 pst=:-moz-non-element< "" > > > > > The empty text node is replaced by a br element. Also, note that the second div element (and all its children) are used to represent the placeholder value. Those frames will go away in bug 553097, so if you currently rely on its existence all the time, your code will break once that bug is fixed.
So after bug 553097 is fixed we will have either text node or br node inside of editor root element (HTML div) depending on editor is initialized or not, right?
Attachment #446436 - Attachment is obsolete: true
Attachment #446436 - Flags: review?(marco.zehe)
Attachment #446436 - Flags: review?(bolterbugz)
Attachment #446436 - Flags: feedback?(ehsan)
Comment on attachment 446436 [details] [diff] [review] patch wrong patch per ehsan comment
mark blocking bug 452599 since once we remove a hack we should get a solution working for contentEditable areas. I think GetPosAndText() should be fixed instead.
Blocks: 452599
(In reply to comment #5) > So after bug 553097 is fixed we will have either text node or br node inside of > editor root element (HTML div) depending on editor is initialized or not, > right? No, you may sometimes not get the second anonymous div. The text node/br behavior on the first anonymous div will remain the same.

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Severity: normal → S3

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Assignee: surkov.alexander → nobody
Status: ASSIGNED → NEW
Attachment #9384490 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: