Closed
Bug 657540
Opened 14 years ago
Closed 14 years ago
Make copying the revision less painful
Categories
(Tree Management Graveyard :: TBPL, defect)
Tree Management Graveyard
TBPL
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: justin.lebar+bug, Assigned: mstange)
References
Details
Attachments
(2 files)
3.92 KB,
patch
|
Swatinem
:
review+
|
Details | Diff | Splinter Review |
1.11 KB,
patch
|
Swatinem
:
review+
|
Details | Diff | Splinter Review |
I often want to copy-paste a cset identifier off TBPL. This is tricky right now because hovering over the changeset link triggers a faux-tooltip showing the full checkin comment. When this tooltip appears, my selection helpfully expands to encompass both the cset id and the checkin comment.
If I want to read the full checkin comment, I can just hover over the comment, so I think it would be useful not to show the tooltip when you hover over the cset id.
Assignee | ||
Comment 1•14 years ago
|
||
Morphing this bug because I have a different fix for the copy problem.
Summary: Hovering over cset link shouldn't expand cset description → Make copying the revision less painful
Assignee | ||
Comment 2•14 years ago
|
||
Clicking left of the revLink currently puts the selection start at the beginning of the div *after* the link. You can test this easily by going into caret mode by pressing F7 in Firefox.
The revLink seems to be skipped by the caret because it's floated. If I float the div after it, too (or make it position:absolute or maybe something similarly "special"), the caret seems to give up and accept its fate to be placed in front of special things, and ends up in front of the revLink. But positioning the rest div absolutely brings all kinds of problems with clipping, so here's a different solution: Instead of floating the revLink, make it display: inline-block, and the div after that, too. I had to add another wrapper div to ensure that the tooltip div (which is position:absolute) ends up in the same place as the non-tooltip one.
Comment 3•14 years ago
|
||
Comment on attachment 533995 [details] [diff] [review]
v1
Review of attachment 533995 [details] [diff] [review]:
-----------------------------------------------------------------
Looks good code-wise, haven’t tested it though.
Attachment #533995 -
Flags: review?(arpad.borsos) → review+
Assignee | ||
Comment 4•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 5•14 years ago
|
||
Has this been pushed to tbpl.m.o? If not, is there some way I can tell once it's been deployed, so I can verify that it's better?
Comment 6•14 years ago
|
||
The easy way to tell would be to shame Markus into not closing bugs until they're deployed, the same way the rest of us got shamed into it :)
The other way would be to switch to using http://dev.philringnalda.com/tbpl-tip/ to see, except you can't really use it, since apparently tip isn't getting anything but push and pending data, which is likely to stand in the way of deploying anything, since people sort of like to see finished results.
Reporter | ||
Comment 7•14 years ago
|
||
Well, it works great on Philor's tbpl. I've lived with the bug for this long; I can wait a bit longer to get it on the main site.
Comment 8•14 years ago
|
||
(In reply to comment #6)
> The other way would be to switch to using
> http://dev.philringnalda.com/tbpl-tip/ to see, except you can't really use
> it, since apparently tip isn't getting anything but push and pending data,
> which is likely to stand in the way of deploying anything, since people sort
> of like to see finished results.
Hm that is working correctly for me. What is not working is that the hover popup is displayed for every changeset, not only for the overflowing ones. Need to take a look at that again… Markus?
Assignee | ||
Comment 9•14 years ago
|
||
(In reply to comment #6)
> The easy way to tell would be to shame Markus into not closing bugs until
> they're deployed, the same way the rest of us got shamed into it :)
Oh, ok. Shaming has occured. :)
> The other way would be to switch to using
> http://dev.philringnalda.com/tbpl-tip/ to see, except you can't really use
> it, since apparently tip isn't getting anything but push and pending data,
Is this still happening for you? Everything works over here.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 10•14 years ago
|
||
Attachment #535121 -
Flags: review?(arpad.borsos)
Comment 11•14 years ago
|
||
Seems sort of unpredictable: sometimes I get spinning forever on tinderbox, sometimes I get a "Loading failed" message and no pending/running.
Comment 12•14 years ago
|
||
Comment on attachment 535121 [details] [diff] [review]
bustage fix
Review of attachment 535121 [details] [diff] [review]:
-----------------------------------------------------------------
I wonder if you could keep using jquery for that. But I guess it’s fine this way.
Attachment #535121 -
Flags: review?(arpad.borsos) → review+
Assignee | ||
Comment 13•14 years ago
|
||
Assignee | ||
Updated•14 years ago
|
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 14•14 years ago
|
||
Wow, this is so much better. Thanks.
Updated•11 years ago
|
Product: Webtools → Tree Management
Updated•10 years ago
|
Product: Tree Management → Tree Management Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•