The default bug view has changed. See this FAQ.

nsTreeView and TreeView.setCellText() is either badly documented, or it doesn't work

NEW
Unassigned

Status

()

Core
XUL
4 years ago
4 years ago

People

(Reporter: Peter Kehl, Unassigned)

Tracking

(Blocks: 1 bug)

26 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

1.75 KB, application/octet-stream
Details
(Reporter)

Description

4 years ago
Created attachment 773149 [details]
Simple XML+Javascript-based XUL to test this - treeCellTest.xul

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

Overview/Summary

Documentation of nsTreeView and also partially current behaviour in Firefox 22, 23bX, 23 debug, 25a1 can lead into interpretation (possibly incorrect), that a developer can override default TreeView methods by assigning to myTreeInstance.view.methodName= ....

However, when I do that for TreeView's setCellText(), it doesn't get trigerred all the time - just on about 1/3rd of changes.




Actual results:

1. Create a simple local chrome extension with the attached XUL
2. Open the XUL (for me it's chrome://selite-settings/content/treeCellTest.xul)
3. double-click at '2nd cell - editable'
4. the cell becomes editable - that's OK
5. type some text, hit Enter
6. the cell either keeps the new text (about 1/3 of tries), or it reverts back to the previous text (about 2/3 of tries).
7. reload the page (using F5 or the refresh icon) and repeat from 3.

If the cell keeps/honours the new text and then you re(re...)edit it again, it keeps/honours the newest text all the time. But if you reload the page, edit the cell and hit Enter and it dishonours the value, then it does it again and again when you re(re...) edit it again.


Expected results:

It's my understanding that setCellText() should be called when the text (contents) of a cell is changed, and the cell should honour the new value. If otherwise, please clarify here and at https://developer.mozilla.org/en-US/docs/XPCOM_Interface_Reference/nsITreeView#setCellText%28%29 

This may be related to https://bugzilla.mozilla.org/show_bug.cgi?id=278536, however I believe this issue affects more users than #278536.
(Reporter)

Comment 1

4 years ago
Indeed, my description is not fully exact, because the bug seems to happen quite randomly, but repeatedly and often. I'd rather not make a video, but if needed, I can make one if you can suggest some free software for Linux to capture video/flash from screen navigation.

Issue happenning on CentOS 6.2 x64 (Firefox 22, 23b4, 23debug), CentOS 6.4 x64 (Firefox 22, 25.0a1).

Updated

4 years ago
Attachment #773149 - Attachment mime type: application/octet-stream → application/vnd.mozilla.xul+xml
(Reporter)

Comment 2

4 years ago
Created attachment 775445 [details]
a simple XPI to test this

The XPI contains index.XUL, similar to treeCellTest.xul that I've attached earlier, but treeCellTest.xul had a minor side bug in it.
Attachment #773149 - Attachment is obsolete: true
(Reporter)

Comment 3

4 years ago
The issue still exists in Firefox 23.0.1 and 24b07 for Linux x64.

There was no comment or investigation done by Mozilla on this since I've created the ticket almost 2 months ago. Shame on Mozilla processes.
(Reporter)

Updated

4 years ago
Component: Untriaged → XUL
Product: Firefox → Core
Version: 22 Branch → 23 Branch
(Reporter)

Comment 4

4 years ago
I get the same buggy/inconsistent/undocumented behaviour when using Firefox 24.0 on Fedora 19 KDE x64.

Minor correct: if you use the attached XPI, then the url for the demonstration is chrome://setcelltext/content/index.xul
(Reporter)

Updated

4 years ago
Version: 23 Branch → 24 Branch
(Reporter)

Comment 5

4 years ago
I get the same behaviour on
- Mac OS X 10.6.8 (Intel, I believe x64), Firefox 24.0
- Windows 7 Pro, Service Pack 1, x64, Firefox 24.0 - however, here I've only seen the bad behaviour (exited text gets reverted back)
OS: Linux → All
(Reporter)

Comment 6

4 years ago
I've checked it with the current Nightly build http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/ > firefox-26.0a1.en-US. I get the same behaviour.

I've also checked on Fedora 19 KDE i686 (32bit) and I get the same behaviour. It's not x64-specific, so I'm changing Platform to All.
Hardware: x86_64 → All
(Reporter)

Updated

4 years ago
Version: 24 Branch → 26 Branch
Hi Peter.
Thanks for the report!
Confirmed in FF 26.0a2 (2013-09-30) Win 7 x64 - the new value is discarded after reload.
Blocks: 278536
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.