Closed Bug 218642 Opened 18 years ago Closed 15 years ago
Caret in textbox overlapping a tree doesn't appear
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.
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.
(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.
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/
Can the owner or submitter please change the status of this bug to NEW. I'll confirm this behaviour too.
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
Verbatim from <http://www.xulplanet.com/ndeakin/tests/stacktree.xul>
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.
(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).
(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.
This should be fixed by the caret changes in bug 167801
No problem anymore with 2006-04-18 trunk build on windows. Testcase is worksforme now. Fixed by bug 287813.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Verified FIXED using build 2006-04-28-05 of SeaMonkey trunk under Windows XP.
Status: RESOLVED → VERIFIED
As far as I can tell, this bug is still present on ff2 (Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:188.8.131.52) 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.
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.