This bug is sprung from comments (comment#28) in bug 114142). In the history sidebar the twisties(show/hide triangles) are unresponsive to mouseclicks. Clicking on them should cause the corresponding folder to open and close. Instead this action can only be accomplished by clicking on the folder or foldername itself. All platforms with 20020320 builds assinged to Ben since he made the "uniform sidebar behavior" changes. *Note this behavior is inconsistent withtheother panels and is History panel only.

*** Bug 131468 has been marked as a duplicate of this bug. ***

*** Bug 135958 has been marked as a duplicate of this bug. ***

Still present in 20020409 Build (x86 Windows XP)

still there 2002041103 - x86 xppro

Why have arrows you can't click on, when in EVERY OTHER ARROW in every other dialogue is clickable? This badly needs a fixin' Problem persists in windows 2000 build 2002041111 from latest 1.0.0 directory.

they open on a right-click instead of a left

it *also* opens on a middle-button click! The only thing that does NOT work is the expected behaviour: open on one left-click.

I would assume this would be a 30 second fix for someone familiar with XUL. Any taker?

Found the fix! but I have ABSOLUTLY no idea why. history.xul and history-panel.xul are very simular files except history.xul has a file menu and multiple colums for dates ect which can be sorted. Anyways I slowly turned history.xul into history-panel.xul untill everything was gone, and it still worked, untill I got to the end of the page. the difference is that you need to add <statusbar id="status-bar" class="chromeclass-status"> <statusbarpanel id="statusbar-display" flex="1"/> <statusbarpanel class="statusbarpanel-iconic" id="offline-status"/> </statusbar> to the end of (right before </page> ) history-panel.xul WHY!!! this makes no sence.

Well. The patch solves it for me. I don't know why, but it does. The problem is that when the twistie is clicked, the item is automatically expanded by some other code. So the actual onClick handler actually collapses the item so it looks like it was never opened. This patch could do evil things to other parts. I really don't know :)

john, the reason your patch worked is because the javascript checks for the absense of a status bar and only then it toggles the item. By adding the status bar, you made it never toggle the item. It's not a real solution though :)

Vadim, the real question is, is the proper fix somewhere on the lines of the patch you summitted, or would it involve fixing the javascript that checks for status, and makes it work anyways. You said "By adding the status bar, you made it never toggle the item", but it appears the by adding the status bar it toggles the item perfectly. But is bailing out of the toggle code when the status bar isn't there.

You didn't read my original comment. When the twistie is clicked, the item is toggled by /some other code/. When the status bar is *not* present, the code *toggles* it again thus *closing it* making it appear it was *never* open.

Ok feeling stupid, I was completly out to lunch when I read your patch. Anyways your patch is in the right direction. Does it fix the double click problem too?

The main problem we are facing is that we could easily cludge this open, but what really needs to happen is for a more centralized system for handling all trees. Currently bookmarks handles the tree with one code (and pretty much works) while history handles it with another code completly different. Anybody care to globalize tree handling? That is more post 1.0 work. So would it be possible for us to just do a temporary hack and either impliment my hack or Vadim's hack both of which made the twisty work but also make it so you have to double click (which is incorrect) and fix it in total later. Is there a bug for centralizing reused js? :)

Claiming.

Oops. Try that again...

The problem is that the historyOnClick hack toggles whether the folder is open or not on a single click. However, twisties already toggle on a single click, so it gets opened here and then closed again later on. It all happens before the display is updated, so you don't see anything happen. Checking if the clicked element is a twisty clears this up.

Please note that the tree is also supposed to expand with a single click on the title itself (including its icon) and not JUST the twisty.

Maybe I wasn't clear the first time. The patch doesn't remove the single click behavior altogether, it just makes twisties work again. There is a hack in the code that opens/closes a folder whenever the user clicks anywhere, including on the twisty. So clicking on a twisty causes the hack to open the folder, and the twisty's normal behavior closes it again, making it look like nothing happened. The patch just excludes the twisty from the hack, so we don't have this double effect. Note that the extra condition is "&& elt.value != "twisty"" and not "&& elt.value == "twisty"". The hack will still toggle folders on a single click, but now the twisties work as expected.

I added a check for the left mouse button and also a check that you were actually clicking in the body and not on the header (to sort) or the column picker.

Comment on attachment 80343 [details] [diff] [review] Extra checks this looks right.. I definitely want a good xul/outliner person to be the r=

Comment on attachment 80343 [details] [diff] [review] Extra checks r=varga

Landed on the trunk.

Asked for drivers approval for 1.0 branch.

Comment on attachment 80343 [details] [diff] [review] Extra checks a=dbaron for 1.0 branch checkin

Landed on branch.

Claudius has agreed to verify this on the trunk and branch...