Status

()

ASSIGNED
8 years ago
4 years ago

People

(Reporter: surkov, Assigned: surkov)

Tracking

(Blocks: 1 bug, {access})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 obsolete attachment)

(Assignee)

Description

8 years ago
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.
(Assignee)

Comment 1

8 years ago
Created attachment 446436 [details] [diff] [review]
patch
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #446436 - Flags: review?(marco.zehe)
Attachment #446436 - Flags: review?(bolterbugz)
Attachment #446436 - Flags: feedback?(ehsan)

Comment 2

8 years ago
What if the editor _is_ initialized?
(Assignee)

Comment 3

8 years ago
(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.

Comment 4

8 years ago
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.
(Assignee)

Comment 5

8 years ago
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?
(Assignee)

Updated

8 years ago
Attachment #446436 - Attachment is obsolete: true
Attachment #446436 - Flags: review?(marco.zehe)
Attachment #446436 - Flags: review?(bolterbugz)
Attachment #446436 - Flags: feedback?(ehsan)
(Assignee)

Comment 6

8 years ago
Comment on attachment 446436 [details] [diff] [review]
patch

wrong patch per ehsan comment
(Assignee)

Comment 7

8 years ago
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

Comment 8

8 years ago
(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.
You need to log in before you can comment on or make changes to this bug.