218642 - Caret in textbox overlapping a tree doesn't appear

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Neil Deakin]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624

The example URL shows that the tree causes the caret to not be drawn. It
contains a XUL stack with a tree and textbox inside it.


Reproducible: Always

Steps to Reproduce:
1. Start typing into the textfield. Caret appears fine at first.
2. The caret will disappear once it gets into the area where it overlaps with
the tree.

Actual Results:  
No blinking caret appears

Expected Results:  
A blinking caret to appear

If this was fixed, editable trees, for example,
http://www.xulplanet.com/ndeakin/tests/edittree.xul could be possible.

Comment 1

[Philippe GOETZ]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

I confirm the bug. I got the same behavious as thoose describe before.

Comment 2

[Philippe GOETZ]

(In reply to comment #1)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
> 
> I confirm the bug. I got the same behavious as thoose describe before.

Looking closer, this seems to be a z-order issue.

Comment 3

[Philippe GOETZ]

I studied the behaviour of the caret. The problem is closely linked to the
frame/view topology. The textbox and its content is drawed in the stack
frame/view context, while the tree is drawed in another overlapping frame/view
context. The onsequence is that the caret in the stack frame/view context is
clipped by the overlapping frame/view contexts.
A easy trunaround is to include the textbox in a frame/view context, e.g. an iframe.

Pseudo-code example:

In the main window:
<window>
  <stack>
    <tree/>
    <iframe top="" left="" width="" height="" src="textbox.xul"/>
  </stack>
</window>

In the iframe window:
<window>
  <textbox/>
</window>

For a full example, you can review the code of "neoez" at the following address:
http://home.tele2.fr/mozware/

Comment 4

[Anko]

Can the owner or submitter please change the status of this bug to NEW.  I'll
confirm this behaviour too.

Comment 5

[Neil Deakin]

This is caused by the more general Views are painted over the cursor bug, so
it's either a duplicate or dependent on that.

Comment 6

[Crash test dummy]

Attachment: Neil Deakin's testcase

Verbatim from <http://www.xulplanet.com/ndeakin/tests/stacktree.xul>

Comment 7

[Crash test dummy]

Attachment: Workaround

Neil Deakin's testcase, but with roc's idea for a workaround from bug 167801
comment 6. Testcase now works fine.

You only have to add
style="overflow:auto"
to the <textbox> and the bug doesn't appear anymore.

I tried the same with Neil's edittree.xml, but the <textbox> then was only half
as high, no idea why.

Comment 8

[Ben Bucksch (:BenB)]

ops. The last 2 comments were from me.

Comment 9

[Harald Albrecht]

(In reply to comment #1)
>If this was fixed, editable trees, for example,
>http://www.xulplanet.com/ndeakin/tests/edittree.xul could be possible.

This example does not work for me any more with trunk SVG-enabled builds, such
as Mozilla 2005022709 or Firefox 1.0+ with Gecko/2005030. The error is in
edittree.xml, method getCellNodeAt: in it there is one line of code that has to
be document.getElementById(col.id) instead of just document.getElementById(col).

Comment 10

[Harald Albrecht]

(In reply to comment #7)
> You only have to add
> style="overflow:auto"
> to the <textbox> and the bug doesn't appear anymore.
> 
> I tried the same with Neil's edittree.xml, but the <textbox> then was only half
> as high, no idea why.

txt.setAttribute("height",outheight.value) in the setEditMode() method is the
culprit. Looks as if there are some layout calculation issues involved when
setting the height property.

Comment 11

[Neil Deakin]

This should be fixed by the caret changes in bug 167801

Comment 12

[Martijn Wargers (dead)]

No problem anymore with 2006-04-18 trunk build on windows. Testcase is worksforme now. Fixed by bug 287813.

Comment 13

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using build 2006-04-28-05 of SeaMonkey trunk under Windows XP.

Comment 14

[Olivier]

As far as I can tell, this bug is still present on ff2 (Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.3) Gecko/20070310) - though it's fixed on trunk.
Would it make sense to have the fix on the 1.8 branch too? - it's an annoying one.

Comment 15

[Martijn Wargers (dead)]

It would make sense to have the fix on the 1.8 branch, but unfortunately the patch is far too risky for that and it depends on other patches that are even more risky.