Caret in textbox overlapping a tree doesn't appear

VERIFIED FIXED

Status

()

defect
VERIFIED FIXED
16 years ago
11 years ago

People

(Reporter: enndeakin, Assigned: janv)

Tracking

Trunk
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

()

Attachments

(2 attachments)

654 bytes, application/vnd.mozilla.xul+xml
Details
676 bytes, application/vnd.mozilla.xul+xml
Details
Reporter

Description

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

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

16 years ago
(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

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

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

Comment 5

15 years ago
This is caused by the more general Views are painted over the cursor bug, so
it's either a duplicate or dependent on that.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

15 years ago
Posted file 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.
ops. The last 2 comments were from me.

Comment 9

15 years ago
(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

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

Comment 11

13 years ago
This should be fixed by the caret changes in bug 167801
Blocks: 201499
Depends on: 287813
No longer depends on: 167801
No problem anymore with 2006-04-18 trunk build on windows. Testcase is worksforme now. Fixed by bug 287813.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Verified FIXED using build 2006-04-28-05 of SeaMonkey trunk under Windows XP.
Status: RESOLVED → VERIFIED

Comment 14

12 years ago
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.
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.

Updated

11 years ago
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.