Search and Top Navigation
#10092 closed bug (invalid)
Opened June 05, 2014 04:43PM UTC
Closed October 22, 2014 08:42AM UTC
Tooltip: Clearing of title attribute while tooltip is open gets reverted on close
Reported by: | ijcheung | Owned by: | ijcheung |
---|---|---|---|
Priority: | minor | Milestone: | none |
Component: | ui.tooltip | Version: | 1.10.4 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
Original title attribute is restored when tooltip is closed if it is set to an empty string while tooltip is open.
Attachments (0)
Change History (9)
Changed June 05, 2014 05:03PM UTC by comment:1
status: | new → open |
---|---|
summary: | Clearing of title attribute while tooltip is open gets reverted on close → Tooltip: Clearing of title attribute while tooltip is open gets reverted on close |
Changed June 06, 2014 04:23AM UTC by comment:2
_comment0: | This seems a bit of a catch-22, as the current design relies on the title attribute being empty while the tooltip is open in order to prevent native tooltips from appearing during mouseover events. \ \ It seems like you'd have to detect the change to title immediately in order to handle the case where the desire is to keep the title attribute as an empty value, however trying to detect the change to the title attribute while the tooltip is open has a few problems as a concept: \ 1. The current implementation works for every case but the empty string \ 2. Browser support for Mutation Events / MutationObserver is limited \ 3. Is the attempt to change the title attribute enough to trigger a detectable event, regardless of the value? (i.e. will no event be fired if the old value and new value are the same, as would be the case here since when tooltip is open the title attribute is indeed empty) \ \ An immediate workaround would be to set the title attr to a single space if you need to clear the title while the tooltip is open, this will at least let you achieve the desired result. \ \ Anyone else have any ideas? → 1402030255600315 |
---|
This seems a bit of a catch-22, as the current design relies on the title attribute being empty while the tooltip is open in order to prevent native tooltips from appearing during mouseover events.
It seems like you'd have to detect the change to title immediately in order to handle the case where the desire is to keep the title attribute as an empty value, however trying to detect the change to the title attribute while the tooltip is open has a few problems as a concept:
1. The current implementation works for every case but the empty string
2. Browser support for Mutation Events / MutationObserver is limited
3. Is the attempt to change the title attribute enough to trigger a detectable event, regardless of the value? (i.e. will no event be fired if the old value and new value are the same, as would be the case here since when tooltip is open the title attribute is indeed empty)
An immediate workaround would be to set the title attr to a single space if you need to clear the title while the tooltip is open, this will at least let you achieve the desired result.
Changed June 06, 2014 05:15AM UTC by comment:3
_comment0: | Doh, that's not a good workaround, as you still get a single space tooltip. Perhaps trimming the title value before copying it over to data-ui-tooltip-title on .open would allow the single-space workaround, but that may not be an acceptable solution. → 1402031862802475 |
---|
Doh, that's not a good workaround, as you still get a single space tooltip. Perhaps trimming the title value and checking for an empty string before copying it over to data-ui-tooltip-title on .open would allow the single-space workaround, but that may not be an acceptable solution.
Changed June 06, 2014 02:01PM UTC by comment:4
owner: | → ijcheung |
---|---|
status: | open → pending |
@ijcheung Can you explain why you're clearing the title
while the tooltip is visible?
Changed June 09, 2014 07:40PM UTC by comment:5
status: | pending → new |
---|
Well, I was using it for an error message. When the item is double clicked it should clear the error and then recheck for the error.
Changed June 13, 2014 05:41PM UTC by comment:6
status: | new → pending |
---|
That sounds like pretty strange UX. Are there any other apps or sites that work like that? How do users know to do this? Why was this decision made for your site?
Changed June 15, 2014 08:37PM UTC by comment:7
status: | pending → new |
---|
It's actually a node-webkit application. Each element would represent a file on the system. Since changes can be made to the file external to the application, this would just give the user the ability to retry after doing just that. There are plenty of desktop applications that do this, so from a UX standpoint, it's a learned behavior.
Changed October 07, 2014 11:50AM UTC by comment:8
status: | new → pending |
---|
Can't you just close the tooltip before changing the title attribute?
Changed October 22, 2014 08:42AM UTC by comment:9
resolution: | → invalid |
---|---|
status: | pending → closed |
Because we get so many tickets, we often need to return them to the initial reporter for more information. If that person does not reply within 14 days, the ticket will automatically be closed, and that has happened in this case. If you still are interested in pursuing this issue, feel free to add a comment with the requested information and we will be happy to reopen the ticket if it is still valid. Thanks!
Confirmed: http://jsfiddle.net/tj_vantoll/4d8Nu/
PR: https://github.com/jquery/jquery-ui/pull/1259