Community
Participate
Working Groups
I opened a page for a repo, checked out a branch. Then went back to all repos page, but the tooltip for the "Checkout branch" action didn't disappear.
Created attachment 210179 [details] Screenshot showing the tooltip
Gosia told me once that there is already a bug raised against this problem. I'll let her find it, if it really exists.
(In reply to comment #2) > Gosia told me once that there is already a bug raised against this problem. > I'll let her find it, if it really exists. I'm not able to find it now. I came across a similar problem when action reloads the page its tooltip sometimes stays and disappears only when another tooltip to other action is opened. Try it out on Merge action on git-status or Delete action on navigator.
there was a more pervasive bug that I fixed where the tooltips stayed up most of the time, this might be a corner case I did not catch.
I don't know about other pages but I see this quite often on the Repositories page. This applies to actions in the upper banner as well ie saw this today for "Init Repository".
(In reply to comment #4) > there was a more pervasive bug that I fixed where the tooltips stayed up most > of the time, this might be a corner case I did not catch. I did some work in bug 360687. I think the culprit in the tooltips getting worse recently is our improved keyboard accessibility. For example see: http://bugs.dojotoolkit.org/ticket/13225 This is fixed in dojo 1.7 but since we aren't shipping on 1.7 I'll need to find a workaround...
Here's an easy way to reproduce the problem. Go to the full repo page. Cursor so that your keyboard cursor is on a repository link. Now hover over any tool (I was hovering over apply patch). Hit the enter key to traverse the link to the repo. The tooltip is now frozen and you can't get rid of it. I'm investigating a fix...
I have a fix. John, I'm requesting you review this because you are good at catching corner cases. If you aren't comfortable with the dojo aspect of it, can you look at it with Mark? The problem here is that we very often empty nodes that contain commands and then rerender the commands based on a new target item. So the "connect node" on the dojo tooltip may in fact get removed from the page. *IF* the tooltip is active when this happens, then it gets stuck on. Now that we have so much more keyboard focus, tabbing, etc...it's so much easier to invoke something by keyboard that causes the tooltip's target node to get removed from the document. I originally tried to tackle this in bug 360687. I started down the path of notifying a tooltip when a command node was removed (there is still some "whenHidden" code in the framework) but for this to work, we would have had to have every command client notify the framework that it was blowing away commands. Or...the framework would have to decide that if you were rendering a set of commands in a node, you probably blew away the old nodes. Neither of these was satisfactory, so I ended up leaving some of the "when hidden" code for future experiments but did not call it anywhere. The main case in that bug was a menu closing and needing its tooltip closed. So...what to do now? I added some polling in the tooltip so that when it's activated, it sets a flag and starts polling to see if its connectNode is still in the document. If it's no longer in the document, then the tooltip closes. Polling stops if the tooltip otherwise closes. Checking to see if something is still alive in a document is not as simple as you might think. We can't check by id because it's likely we rerendered a command with the same id. We can't simply check parentNode because the parent chain doesn't get disconnected all the way down. Only in the place where the dojo.empty got removed. So we have to walk the parent chain and see if we end up at the document. To see that the fix works, try to find a case where your keyboard focus is somewhere that will "AJAX reload" the document...ie, change the target, rerender the commands, etc. Then hover over a command that you know will get rmeoved/replaced. Without this fix, the tooltip is forever stuck on, unless you reload the document or hover over another command and invoke its tooltip. I'm not a big fan of polling, but this was the best solution I could come up with. The only way to avoid polling is to force all clients to call tooltip bashing code whenever they rerender commands, etc. I propose we fix this because it looks really dumb when the tooltip gets stuck.
I opened bug 371698 for either removing whenHidden or making it real. I should have done that before when I left it in to think about it.
I hope this isn't a dumb question, but couldn't you attach some DOM listener to the connectNode to find out if it gets removed from the document, and blow away the tooltip when that happens? There's a "DOMNodeRemovedFromDocument" event that seems like the right thing: https://developer.mozilla.org/en/DOM_Client_Object_Cross-Reference/DOM_Events
(In reply to comment #10) > I hope this isn't a dumb question, but couldn't you attach some DOM listener to > the connectNode to find out if it gets removed from the document, and blow away > the tooltip when that happens? There's a "DOMNodeRemovedFromDocument" event > that seems like the right thing: > https://developer.mozilla.org/en/DOM_Client_Object_Cross-Reference/DOM_Events I've never known you to ask a dumb question, Mark. I had searched for that back in M1 when I was first looking at that problem and had found some discussion about browser differences and the whole "parent chain" workaround. It could have been old discussion...Let me try an alternate patch and test. John..stand by.
(In reply to comment #11) > I've never known you to ask a dumb question, Mark. I had searched for that > back in M1 when I was first looking at that problem and had found some > discussion about browser differences and the whole "parent chain" workaround. > It could have been old discussion...Let me try an alternate patch and test. > John..stand by. I've put an alternate commit in the remote branch origin/bug369923DOMEvent It is much cleaner, and it works great on FF and Chrome. However, it does not work on IE, whereas the first solution does. I found some very old bugs discussing dojo not normalizing the DOM events [1], and the solution back then normalized DOMNodeRemoved but not DOMNodeRemovedFromDocument. So it could be any of: - the alternate fix needs to not use dojo connect and ensure the right browser-appropriate event names are used - IE is not supporting the event as we expect. I found an old reference saying DOMNodeRemovedFromDocument fires when a node is inserted into a different document. I didn't know whether to take that literally (in this case it's just being removed, not inserted somewhere else.) - we could also investigate DOMNodeRemoved but we need to understand whether this can be placed on the element or whether it has to be placed on its container. And how picky is it? If someone empties an element that is the parent of the parent of the command, will we get the event? [1] http://bugs.dojotoolkit.org/ticket/1405 [2] http://docstore.mik.ua/orelly/webprog/dhtml/ch10_01.htm We are running out of runway for RC2, Mark is going to investigate while I attend a meeting...
Had to switch gears to address a problem with the fix for another bug, but here's what I found so far: The implementation of dojo.empty() is special-cased for IE. It's written in such a way that DOMNodeRemovedFromDocument events do not fire (the 'removed' nodes aren't actually removed from the document, they're removed from their parent and added to a dummy holding container which happens to be in the same document). So I guess that leaves "DOMNodeRemoved" or going back to polling.
(In reply to comment #13) > So I guess that leaves "DOMNodeRemoved" or going back to polling. As Susan suspected, DOMNodeRemoved does not fire on the descendants of a removed node, so it won't work for us.
Reviewed and tested the fix in Comment 8 (polling). +1
pushed fix
(In reply to comment #13) > The implementation of dojo.empty() is special-cased for IE. It's written in > such a way that DOMNodeRemovedFromDocument events do not fire (the 'removed' > nodes aren't actually removed from the document, they're removed from their > parent and added to a dummy holding container which happens to be in the same > document). Actually, I take this back. I can't even make DOMNodeRemovedFromDocument work in FF/IE for trivial cases. Not sure why the patch in Comment 12 worked in Firefox at all. Weird :(
