These two changes seem relevant (14067 and 2943):
r14067 | hqm | 2009-06-05 11:34:49 -0400 (Fri, 05 Jun 2009) | 58 lines
Change 20090605-hqm-Q by [email protected] on 2009-06-05 11:30:43 EDT
in /Users/hqm/openlaszlo/trunk5
for http://svn.openlaszlo.org/openlaszlo/trunk
Summary: fix for text selection in DHTML
New Features:
Bugs Fixed: LPP-8200
Technical Reviewer: max
QA Reviewer: andre
Doc Reviewer: (pending)
Documentation:
Release Notes:
Details:
+ LzSprite.js: only toggle the focus in focus_on_mouseover quirk when
there is some text selected.
+ LzKeyboardKernel.js: Instead of cancelling a mouse event completely,
just cancel bubbling. This lets the div handle the event, and allows
text selection to work, but should disable it from propagating to
global handlers.
+ LzTextSprite.js: use correct CSS properties for toggling
selectability, in Safari
+ LzInputTextSprite.js: do not bind the global document.onselectstart
handler, that prevents
text selection from working in some browsers
+ LzText.lzs: add the 'onselectable' event, not required for this
patch, but I noticed it was missing when writing a test case
Tests:
+ added lpp-8200.lzx test, try selecting a region in each the text
fields, except for the last (non-selectable) one.
+ text selection should work in DHTML on selectable text or input
text, all
browsers
+ tested tabbing behavior of examples/components/
component_sampler.lzx?lzt=html&lzr=dhtml
in IE7, FF3(OSX), Safari(OSX). You can tab to all input text elements.
This is based on the
original comment from [r2943 | max | 2006-12-06 23:49:36 -0500 (Wed,
06 Dec 2006) ]
Tests: Tabbing to select inputtexts and typing now works for for the
testcase for LPP-3197 and
http://localhost:8080/legals/examples/components/style_example.lzx?lzr=dhtml
.
LzKeyboardKernel.js prevents bubbling for tab key events.
LzMouseKernel.js has more safety checking. LzInputTextSprite.js now
implements focusing and blurringi, selection and deselection
properly.
LzTextSprite.js and LzInputTextSprite.js now track global UID
properly.
r2943 | max | 2006-12-06 23:49:36 -0500 (Wed, 06 Dec 2006) | 29 lines
Change 20061206-maxcarlson-6 by [email protected]
on 2006-12-06 17:37:39 PST
in /Users/maxcarlson/openlaszlo/legals
Summary: Fix DHTML inputtext tabbing and selection
New Features:
Bugs Fixed: LPP-3197 - DHTML: Tabbing between inputtext elements
doesn't work
Technical Reviewer: promanik
QA Reviewer: hminsky
Doc Reviewer: (pending)
Documentation:
Release Notes:
Details:
Tests: Tabbing to select inputtexts and typing now works for for the
testcase for LPP-3197 and http://localhost:8080/legals/examples/components/style_example.lzx?lzr=dhtml
. LzKeyboardKernel.js prevents bubbling for tab key events.
LzMouseKernel.js has more safety checking. LzInputTextSprite.js now
implements focusing and blurringi, selection and deselection
properly. LzTextSprite.js and LzInputTextSprite.js now track global
UID properly.
Files:
M WEB-INF/lps/lfc/kernel/dhtml/LzKeyboardKernel.js
M WEB-INF/lps/lfc/kernel/dhtml/LzMouseKernel.js
M WEB-INF/lps/lfc/kernel/dhtml/LzInputTextSprite.js
M WEB-INF/lps/lfc/kernel/dhtml/LzTextSprite.js
On 2009-06-30, at 23:03EDT, Henry Minsky wrote:
So ... does anyone remember what the __cancelKeys flag is supposed
to be
doing for us?
Is this block of code now obsoleted by the call to updateControlKeys?
On Tue, Jun 30, 2009 at 10:45 PM, Henry Minsky <[email protected]
>wrote:
Hmm, there's this code in LzSprite which does muck with the event,
it even
has a warning from andre...
// FIXME: [20090602 anba] this prevents text selection,
see
LPP-8200
if (LzKeyboardKernel.__cancelKeys && e.keyCode == 0) {
e.cancelBubble = true;
e.returnValue = false;
}
On Tue, Jun 30, 2009 at 8:41 PM, P T Withington <[email protected]>
wrote:
We must be doing something more than just attaching the handler.
We must
be somehow stifling the event. Normally events go to the inner-
most DOM
element first. The only way I can think that the iframe could
prevent an
inner element from getting onclick is if it registers for the
'capture'
phase (which means it has to pass 'true', I think as the last arg to
attachEventHandler? That's the only way an outer element can get
hold of an
event before an inner one.
On 2009-06-30, at 19:27EDT, Henry Minsky wrote:
well, a simple test case doesn't show the bug, I can attach an
onclick
handler onto
the main document of an iframe, and I can attach an onclick
handler onto
a
span of text
in the iframe, and clicking fires both handlers.
So I guess I need to make a more detailed model of what we're
doing with
the
event
handler attacher in lz.embed.
On Tue, Jun 30, 2009 at 6:52 PM, Henry Minsky <[email protected]
wrote:
Well, we're installing the event handlers for mousedown and click
onto
the
actual iframe element in the DHTML app, so maybe that just stops
the
event
from propagating into the iframe, in Safari and IE7. I'll set up a
simple
test case to see if that is the case. Maybe the whole 'capture/
bubble'
model
gets broken if it crosses an iframe boundary in the browser.
On Tue, Jun 30, 2009 at 4:27 PM, P T Withington <[email protected]>
wrote:
Well something is weird because normally _adding_ a handler to
mouse
click
does not cancel/intercept the event. If you just add a handler
and
don't
call suppressDefault or cancelBubble, then the event should be
seen by
all
the listeners (and by the browser default action).
I know you were working in this area recently with respect to the
keyboard
update method that tries to pick off the shift keys from the
mouse
event.
Maybe something went awry there? Or maybe the way the iframe
manager
is
registering to listen to mouse events it screwing things up.
If you listen in the 'capture' phase (i.e., grab the event
before it is
sent to any DOM elements, you can intercept the event; but I
did not
think
we did that.
On 2009-06-30, at 16:00EDT, Henry Minsky wrote:
The text selection getting nuked is a bug in safari. The
inability to
click
on a <a> link happens
in both safari and IE7 (it is due to the intercept of the
'click'
event)
On Tue, Jun 30, 2009 at 3:58 PM, P T Withington <[email protected]>
wrote:
On 2009-06-30, at 15:20EDT, Henry Minsky wrote:
I isolated the bug in http://openlaszlo.org/jira/browse/LPP-8303down
to
this code in iframemanager.js
in __setSendMouseEvents , the iframemanager binds the
'mousedown'
and
'click' events
lz.embed.attachEventHandler(iframe.document,
'mousedown',
lz.embed.iframemanager, '__mouseEvent', id);
lz.embed.attachEventHandler(iframe.document, 'click',
lz.embed.iframemanager, '__mouseEvent', id);
And those cause Safari to no longer be able to drag-select
text or
to
click
on links.
Is there some way we can re-send those events back to the
browser,
if
thise
code is intercepting them?
These events all bubble, but are also all cancellable. Is the
event
handler cancelling them or suppressing the default action?
We're not grabbing these events in capture phase (before any
DOM
element
gets to see them) are we?
Is this _only_ a bug in Safari?
--
Henry Minsky
Software Architect
[email protected]
--
Henry Minsky
Software Architect
[email protected]
--
Henry Minsky
Software Architect
[email protected]
--
Henry Minsky
Software Architect
[email protected]
--
Henry Minsky
Software Architect
[email protected]
