<br><br><div class="gmail_quote">On Thu, Jun 4, 2009 at 9:44 AM, P T Withington <span dir="ltr"><<a href="mailto:ptw@pobox.com">ptw@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I have a couple of comments:<br>
<br>
o Should we be browser-switching in getSelectedText, rather than probing for functions? If we do probe for functions, are we doing it in the right order (which to me would be: 1) DOM2 Standard, 2) IE, 3) Firefox, 4) etc.<br>
<br>
o Similarly, should we use browser-switching to insert the appropriate browser-specific CSS, rather than just shoving them all in there? I can imagine there might be a performance penalty for stray styles, or even a confusion if a browser tries to emulate another.</blockquote>
<div><br>Yeah, conditionalizing on browser type would be a more deterministic<br>
than probing for features. I guess it does seem a little too much wishful-programming to think that<br>
by seeing that some function is in the environment that things will magically work in some unknown browser.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
o I'm confused as to why we have both Khtml- and Webkit- specific styles. I thought Webkit was the new Khtml? Is there still a Khtml browser that is not Webkit?<br>
</blockquote><div><br>Hmm, I guess there probably aren't any KDE browsers out there that we need to worry about.. (was it Konqueror? That's so 1998...) <br><br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
o Can you put a comment where you removed "// FIXME: [20090602 anba]", explaining what is being done, so future generations will not be mystified? (e.g., "We have handled the event, so we stop propagation to outer divs, but, we still want the browser default action (e.g., select in an input text) to occur, so we _don't_ return false.") Even better, to my mind, would be to use the actual DOM2 interface to the event and call `.stopPropagation()`, but not `.preventDefault()`.<div>
<div></div><div class="h5"></div></div></blockquote><div><br>Yeah, I have to make sure I understand which bug cases that code was trying to avoid when it cancelled the events entirely, and check that they are not brought back to life by this change. Max suggested putting in a debug print to see which event it is that we are cancelling that specifically is causing text selection to break, whether it is the<br>
mouse-down or maybe the mouse-moves, I should verify that for future reference, and make a comment. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div class="h5"><br>
<br>
On 2009-06-03, at 22:56EDT, Henry Minsky wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Change 20090603-hqm-U by hqm@badtzmaru.home on 2009-06-03 22:27:28 EDT<br>
in /Users/hqm/openlaszlo/trunk5<br>
for <a href="http://svn.openlaszlo.org/openlaszlo/trunk" target="_blank">http://svn.openlaszlo.org/openlaszlo/trunk</a><br>
<br>
Summary: fix for text selection in DHTML<br>
<br>
New Features:<br>
<br>
Bugs Fixed: LPP-8200<br>
<br>
Technical Reviewer: max<br>
QA Reviewer: andre<br>
Doc Reviewer: (pending)<br>
<br>
Documentation:<br>
<br>
Release Notes:<br>
<br>
Details:<br>
<br>
+ LzSprite.js: only toggle the focus in focus_on_mouseover quirk when there is some text selected.<br>
<br>
+ LzKeyboardKernel.js: Instead of cancelling a mouse event completely,<br>
just cancel bubbling. This lets the div handle the event, and allows<br>
text selection to work, but should disable it from propagating to<br>
global handlers.<br>
<br>
+ LzMouseKernel.js: don't cancel event with keyCode == 0 entirely, just cancel bubbling.<br>
<br>
+ LzTextSprite.js: use correct CSS properties for toggling selectability, in Safari<br>
<br>
+ LzInputTextSprite.js: do not bind the global document.onselectstart handler, that prevents<br>
text selection from working in some browsers<br>
<br>
+ LzText.lzs: add the 'onselectable' event, not required for this<br>
patch, but I noticed it was missing when writing a test case<br>
<br>
Tests:<br>
<br>
+ added lpp-8200.lzx test, try selecting a region in each the text<br>
fields, except for the last (non-selectable) one.<br>
<br>
+ text selection should work in DHTML on selectable text or input text, all<br>
browsers<br>
<br>
+ NOTE: there is a bug in IE7 text selection [maybe related to<br>
(LPP-8249) "IE7 DHTML text letter spacing looks bad"], where in the<br>
test case lpp-8200, if you try to drag the mouse to select the text in<br>
the <text> view which says "This is selectable text", you cannot use<br>
the mouse to select the last word ('text'). I think that maybe the<br>
letter spacing setting causes the browser to miscalulate the text<br>
width?<br>
<br>
Files:<br>
A test/lfc/lpp-8200.lzx<br>
M WEB-INF/lps/lfc/kernel/dhtml/LzKeyboardKernel.js<br>
M WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js<br>
M WEB-INF/lps/lfc/kernel/dhtml/LzTextSprite.js<br>
M WEB-INF/lps/lfc/kernel/dhtml/LzMouseKernel.js<br>
M WEB-INF/lps/lfc/kernel/dhtml/LzInputTextSprite.js<br>
M WEB-INF/lps/lfc/views/LzText.lzs<br>
<br>
Changeset: <a href="http://svn.openlaszlo.org/openlaszlo/patches/20090603-hqm-U.tar" target="_blank">http://svn.openlaszlo.org/openlaszlo/patches/20090603-hqm-U.tar</a><br>
</blockquote>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Henry Minsky<br>Software Architect<br><a href="mailto:hminsky@laszlosystems.com">hminsky@laszlosystems.com</a><br><br><br>