Skip to content


Subversion checkout URL

You can clone with
Download ZIP


Hover and Click only work over Part of a Glued Span #330

JohnWSaundersIII opened this Issue · 26 comments

4 participants


I'll get you more detail later, but I only just now reproduced this, and wanted to get you the information I have.

I have seen this for a while, that copying doesn't always work over the entire width of a span. In particular, for copying an email address, I've seen it work at the beginning of the address, but not always at the end. I was never able to tie this down.

I happen to have had the HTML tab of Firebug open while I was clicking in my page. As I moved the mouse cursor over the span, I noticed that you add the zeroclipboard-is-hover class to the span.

I also noticed that when the cursor moved over the "@" sign of the email address, the zeroclipboard-is-hover class was removed.

This may be a clue to someone who knows the code.

More clues. I turned on logging of mouse events for that span, started the mouse pointer before the span, and slowly moved the mouse from left to right. Here's what I saw:

mouseover clientX=100, clientY=133 » span#ctl00__ctl01_emailLabel.MCD_A_Control_HasClick
mousemove clientX=100, clientY=133 » span#ctl00__ctl01_emailLabel.MCD_A_Control_HasClick
mouseout clientX=100, clientY=133 » span#ctl00__ctl01_emailLabel.MCD_A_Control_HasClick
mouseover clientX=181, clientY=132 » span#ctl00__ctl01_emailLabel.MCD_A_Control_HasClick
mouseout clientX=181, clientY=132 » span#ctl00__ctl01_emailLabel.MCD_A_Control_HasClick

In other words, there was one mouse{over,move,out} when the pointer first moved over the span. There was another mouse{over,out} when the pointer reached the first character after the "@". Note, no new mousemove.

This was with Firefox 26.0 running on Windows 7 Ultimate, using zeroclipboard 1.2.3.


Well, here's a pleasant surprise: the issue has nothing to do with an "@" in the span.

I changed the app so that the user's name is displayed, yet the email address is to be copied (data-clipboard-text). The same problem occurs:

mouseover clientX=390, clientY=268 » span#ctl00__ctl02_userLabel.MCD_A_Control_HasClick
mousemove clientX=390, clientY=268 » span#ctl00__ctl02_userLabel.MCD_A_Control_HasClick
mouseout clientX=390, clientY=268 » span#ctl00__ctl02_userLabel.MCD_A_Control_HasClick
mouseover clientX=451, clientY=266 » span#ctl00__ctl02_userLabel.MCD_A_Control_HasClick
mouseout clientX=454, clientY=266 » span#ctl00__ctl02_userLabel.MCD_A_Control_HasClick


I'd assume this is related to the span's display:inline nature. See long-standing Issue #102 for my original suggestion to test such.

These can't really all be covered, such as if a display:inline element wraps onto a 2nd, 3rd, etc. line of text.


FYI, the spans involved take only one line. In fact, the latest is inside of a table:

      <label for="theSpan">label:</label>
      <span data-clipboard-text="" title="hover text">User name</span>

When I get closer to done with my many other bugs, I will try to get you a reproducer.


How about if you set display:inline-block; on the span?


What are the actual height and width of the span (e.g. using Chrome DevTools) compared to the height and width that ZeroClipboard seems to think it is?


Layout tab in Firebug says that it is 122x14, and this appears to be the case. There is no margin or padding.


Is that for the original use case where ZeroClipboard thought it was 80px wide, or the second where it was ~60px wide?


Sorry, you've been the victim of rapid UI changes. Here are today's numbers (what I hope is near-final):

mouseover clientX=393, clientY=231 » span#ctl00_Control_ctl06_userEmailLabel.MCD_A__HasClick
mousemove clientX=393, clientY=231 » span#ctl00_Control_ctl06_userEmailLabel.MCD_A__HasClick
mouseout clientX=393, clientY=231 » span#ctl00_Control_ctl06_userEmailLabel.MCD_A__HasClick
mouseover clientX=493, clientY=227 » span#ctl00_Control_ctl06_userEmailLabel.MCD_A__HasClick
mouseout clientX=497, clientY=227 » span#ctl00_Control_ctl06_userEmailLabel.MCD_A__HasClick

Here are some of the DOM properties of this span and some of its parents. Please let me know if you need more of them:


Name Value
clientHeight 0
clientLeft 0
clientTop 0
clientWidth 0
offsetHeight 14
offsetLeft 64
offsetParent td
offsetTop 2
offsetWidth 126
scrollHeight 14
scrollWIdth 126


Name Value
clientHeight 18
clientLeft 0
clientTop 0
clientWidth 239
offsetHeight 18
offsetLeft 269
offsetParent table
offsetTop 72
offsetWidth 239
scrollHeight 18
scrollWIdth 239


Name Value
clientHeight 90
clientLeft 0
clientTop 0
clientWidth 508
offsetHeight 90
offsetLeft 36
offsetParent div
offsetTop 528
offsetWidth 508
scrollHeight 90
scrollWIdth 508


Name Value
clientHeight 1009
clientLeft 0
clientTop 0
clientWidth 580
offsetHeight 1009
offsetLeft 24
offsetParent body
offsetTop 174
offsetWidth 580
scrollHeight 1009
scrollWIdth 580


Name Value
clientHeight 1221
clientLeft 0
clientTop 0
clientWidth 967
offsetHeight 1221
offsetLeft 0
offsetParent null
offsetTop 0
offsetWidth 967
scrollHeight 1235
scrollWIdth 967

Condensed version:

  span td table div body
clientLeft 0 0 0 0 0
clientTop 0 0 0 0 0
clientWidth 0 239 508 580 967
clientHeight 0 18 90 1009 1221
offsetParent td table div body null
offsetLeft 64 269 36 24 0
offsetTop 2 72 528 174 0
offsetWidth 126 239 508 580 967
offsetHeight 14 18 90 1009 1221
scrollWidth 126 239 508 580 967
scrollHeight 14 18 90 1009 1235

Here's a little more data:

  1. Just to reduce the variables, I changed the font to monospace. Still have the same problem.
  2. I added a complete handler to .fadeOut().fadeIn() to make it easier to see when the data are actually being copied. You'll be pleased to know that the completed event does correspond to when the data are copied!
  3. Every copyable span had a CSS class on it which set the cursor to pointer, to indicate that it was something that could be clicked. Yet the cursor returns to normal when it was over an area where the copy fails.
  4. As an experiment, I removed the cursor:pointer; style - the problem still occurs.

Yet the cursor returns to normal when it was over an area where the copy fails.

The copy isn't failing, it's just that the Flash object is not being resized to large enough dimensions to cover your whole span. You could add a CSS border to both the Flash object (by ID/class selector) and your spans to see what I mean.


Maybe it's too early in the morning (no, it is too early in the morning), but I don't get how I would determine the ID/class selector of the Flash object.


Through the magic of open source! :crystal_ball:

(Sorry, didn't exactly mean the Flash object but rather its div container.)


We use Element#getBoundingClientRect and a few supplemental adjustments (e.g. the page's text size due to browser zooming — but not CSS zoom-ing [yet], see #149) to calculate the size and position of the clipped element.

If you can figure out the exact dimensions of your span elements programmatically, then:

A. You could manually patch it on mouseover, e.g.:

client.on("mouseover", function(client) {
  // `this` === current clipped element being hovered over

  // Maybe try leveraging jQuery...? They have much more robust calculations for this stuff.
  var $this = jQuery(this);
  client.setSize($this.width(), $this.height());


B. You can let us know how to did it and we can assess if it's safe enough to patch ZeroClipboard with (especially important since the plan is to remove client.setSize from the public API in v2.0.0, though you could still manually ).


As a worst-case patch, you could consider attempting to clip the containing td element rather than the span. This would make the whole td a "copy button" but, if it's acceptable to your clients/business, may still be a better option than not having the whole span clickable.


Doesn't seem like there is any way to get the dimensions of an inline element unless they have been explicitly set (via CSS, inline styles, etc.). :astonished:



Reason: It is not currently possible to get used values from the DOM... only computed values. Dimensions and positioning all pend on the page layout, ergo their used values can often differ from their computed values.

IIRC, @timmywil (Dec. 1 edit: or @mikesherov?) was working with the HTMLWG to add some sort of functionality to get the used values (:+1:) — perhaps "getUsedStyle" — but it is not implemented yet. (:-1:)

@jonrohan jonrohan added the help-wanted label
@JamesMGreene JamesMGreene added this to the Release 2.x (>= 2.1) milestone

Related: #495 ("Create positioning unit tests")

@JamesMGreene JamesMGreene added the CSS label

It's actually a bit more hazy than that. getComputedStyle actually gets resolved values:

Yes, used values should theoretically work, but so should getBoundingClientRect. I think this may be a bug. It might be worth bringing it up on the www-style mailing list.


Thanks for the feedback, @mikesherov.

I'll try to get something out to the www-style group soon.


Maybe this was fixed in browser releases this year...? I can't seem to reproduce it now in any browser (Safari, Firefox, Chrome, Opera) on my MacBook Pro.

See dev console when viewing this JSBin:

@JohnWSaundersIII, if you could make a simple fork of this JSBin (edit view) that can still reproduce this zero-width-but-visible-with-contents-span problem (without ZeroClipboard, ideally), that would be much appreciated.


@JamesMGreene it might have something to do with whether the element is disconnected or not.


@mikesherov: You mean detached from the DOM, right? I unfortunately don't remember what page I was querying against in my past code snippets (screenshots above) but the span in question was definitely attached. Not 100% certain it was visible, though, since I didn't include that in my check back then [unlike in my new JSBin]... but I am very doubtful that I would've tested against something that wasn't.


@JamesMGreene sorry, but I no longer work for that company, have no access to the code, etc.


Well nuts, @JohnWSaundersIII... isn't that always the way? :stuck_out_tongue:

I'll leave the issue around for a bit in case anyone else runs into a similar situation (or takes the time to reproduce it) but if I don't get any updates by, say, January 1st, I'll probably just close this out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.