Re: text selection and links not working in iframe (html element) in Safari
P T Withington <ptw <at> pobox.com>
2009-07-01 15:20:14 GMT
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
On Jul 3, 2009, at 12:32 AM, P T Withington wrote:
> This would be very cool to implement. I guess the big problem lies
> with finding fonts that you are allowed to distribute!
>
> On 2009-07-02, at 18:11EDT, Raju Bitter wrote:
>
>> I created a new JIRA issue for support of downloadable fonts in the
>> DHTML runtime. That's supported in FF 3.5 and Safari already,
>> here's the issue.
>> 
RSS Feed