[Laszlo-dev] text selection and links not working in iframe (html element) in Safari

P T Withington ptw at pobox.com
Wed Jul 1 08:20:14 PDT 2009 

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 hqm at badtzmaru.home 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 maxcarlson at max-carlsons-computer.local  
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 <hminsky at laszlosystems.com 
> >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 <ptw at pobox.com>  
>> 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 <hminsky at laszlosystems.com
>>>>> 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 <ptw at pobox.com>  
>>>>> 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 <ptw at pobox.com>
>>>>>>> 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
>>>>>>> hminsky at laszlosystems.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Henry Minsky
>>>>> Software Architect
>>>>> hminsky at laszlosystems.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Henry Minsky
>>>> Software Architect
>>>> hminsky at laszlosystems.com
>>>>
>>>
>>>
>>
>>
>> --
>> Henry Minsky
>> Software Architect
>> hminsky at laszlosystems.com
>>
>>
>>
>
>
> -- 
> Henry Minsky
> Software Architect
> hminsky at laszlosystems.com

More information about the Laszlo-dev mailing list