Comments

• omastudios

  February 2012

  Add this to the object's class (or to it's style property):
  
  -webkit-user-select:text;

  0 · Share on Twitter
• rsanchez1

  February 2012

  Hey guys, I stopped working on making the text selectable a while back, but now I'm back on it, and adding that CSS declaration didn't make the text selectable. Is there something else enyo-related that could be preventing the text from being selectable? The HtmlContent kind is in a ScrollerKind, which is in a VFlexBox inside of a SlidingPane.

  0 · Share on Twitter
• unwiredben

  February 2012

  Check the styles in Chrome's web inspector view. It may be that your style needs to be marked !important to override a more specific selector in the enyo CSS files.

  0 · Share on Twitter
• rsanchez1

  February 2012

  I did
  
  * {-webkit-user-select: text !important;}
  
  And no luck.

  0 · Share on Twitter
• isuhendro

  February 2012

  Follow unwiredben suggestion to check at web inspector view, and try modify the CSS definition there

  0 · Share on Twitter
• rsanchez1

  February 2012

  Nothing in the web inspector shows that -webkit-user-select is being overriden, and adding it there does nothing.

  0 · Share on Twitter
• unwiredben

  February 2012

  OK, there's another CSS flag that's used here. Looking at the enyo-1.0 source, the .enyo-richtext class definition has

  .enyo-richtext {
  	-webkit-user-select: text;
  	-webkit-user-modify: read-write;
  	-webkit-line-break: after-white-space;
  }

  That -webkit-user-modify part looks important.
  
  The app.css for the API docs provide this class definition

  .selectable {
  	-webkit-user-select: text;
  	cursor: text;
  }

  that works to make the documentation text selectable.

  0 · Share on Twitter
• rsanchez1

  February 2012

  What you suggested still won't make text selectable.
  
  However, I did try something that made me think this is a JS problem with Enyo. If I do:
  
  enyo = null;
  
  in the webkit inspector console, the text becomes selectable. However, it still requires
  
  -webkit-user-select: text;
  
  That made me think that something in enyo must be preventing the drag event from bubbling up to make the text actually selectable. So I did a search in enyo-build.js looking for preventDefault, and found the method that breaks it. Doing:
  
  enyo.gesture.mousedown = null;
  
  Finally makes the text selectable, without just nuking all of enyo. It does disable anything enyo that did have to do with mousedown, so I just rewrite the functions in my JS so that anything that did preventDefault didn't happen anymore, something like:

  enyo.gesture.mousedown = enyo.bind(enyo.gesture, function(a) {...});
  enyo.gesture.sendCustomMousedown = function(a) {...}); //didn't use "this" in enyo, so didn't need binding

  with a.preventDefault removed.
  
  This allows anything that had to do with mousedown to still work, and doesn't break anything else as far as I could tell. Is there a reason why preventDefault was put in there?

  0 · Share on Twitter
• unwiredben

  February 2012

  Yeah -- if you look in the source, you'll see that not preventing that event causes some really bad scrolling performance problems.

  0 · Share on Twitter
• rsanchez1

  February 2012

  It's always that scrolling.
  
  Oh well, I really only need it in Chrome, so I have a check in the code to see if I'm in Chrome and then modify enyo.gesture.mousedown and enyo.gesture.sendCustomMousedown. I don't need those for scrolling in Chrome.
  
  Thanks for the help!

  0 · Share on Twitter