Issue Details (XML | Word | Printable)

Key: LPP-5447
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: P0 P0
Assignee: Max Carlson
Reporter: André Bargull
Votes: 0
Watchers: 3

If you were logged in you would be able to see more operations.

DHTML: inputtext and clickable

Created: 19/Feb/08 05:57 AM   Updated: 29/Jul/09 05:00 PM
Component/s: Kernel - DHTML
Affects Version/s: RingDing (4.1)
Fix Version/s: 4.5

Time Tracking:
Not Specified

File Attachments: 1. File lpp-5447.lzx (0.6 kB)
2. HTML File test.html (2 kB)

Image Attachments:

1. .jpg
(79 kB)
Issue Links:

Severity: Blocker
Actually Fixed In: 4.5
Fixed in Change#: 14,407
Runtime: DHTML
Flags: Diamond
Fix in hand: False

 Description  « Hide
The "inputtext - clickable" workarounds and special tricks cause some bugs:

Steps to reproduce:
(at least in Firefox2, IE6)
- go to "examples/components/style_example.lzx?lzr=dhtml"
- expand the frosty-window, so it's big enough to cover the inputtext on the right hand side
- hover over the inputtext, or alternatively focus the inputtext by tab-key
- the inputtext's text will become visible

from time to time, the whole application did not receive any mouse-clicks anymore,
the only way to resurrect the app, was to change focus by tab-key until I've focused the inputtext,
after the inputtext gained focus, the app was again able to receive mouse-events.

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
Max Carlson added a comment - 19/Jun/08 05:06 PM
LPP-5430 should resolve the issue with apps not receiving mouse clicks in IE.

I'm not sure what to do about the other issues :( Input texts have to be placed in the of the clickable elements (which are in their own tree of divs) to become active.

André Bargull added a comment - 09/Dec/08 11:08 AM
see also LPP-3352

André Bargull added a comment - 06/May/09 10:33 AM
Maybe we can use "document.elementFromPoint(...)" to check if the inputtext needs to be made active when the mouse moves over it's clickable sprite.

Amy Muntz added a comment - 02/Jul/09 08:49 AM
Just filed dup in context of webtop. Escalating this.

Max Carlson added a comment - 07/Jul/09 02:59 PM
See LPP-8316 for the new dup

Max Carlson added a comment - 07/Jul/09 03:00 PM
We could use document.elementFromPoint(...) to handle mouse events but that wouldn't help when tabbing into the inputtext - as this bug describes...

P T Withington added a comment - 16/Jul/09 08:22 AM
Assigning to me, since the dup was assigned to me.

P T Withington added a comment - 16/Jul/09 08:27 AM
[This is clearly due to our 'clickdiv' kludge. Adding what I know about that:]

Date: Tue, 17 Feb 2009 20:07:10 -0800
From: Max Carlson <>

I'll write something here first, then update the comments later.

P T Withington wrote:
> On 2009-02-13, at 23:06EST, Max Carlson wrote:
>> ) There may be side effects from setting __LZclickdiv.className =
>> 'lzclickdiv' instead of 'lzdiv'. If you're doing this to improve
>> debugging, I'd suggest using a separate class name, maybe
>> 'lzclickdivcontainer'? See LzInputTextSprite#__setglobalclickable()
>> which shows/hides all divs named 'lzclickdiv' in some cases.
> Could one or both of you please write some documentation for the DHTML
> kernel that explains the purpose of clickdivs?

Clickdivs exist to have independent control over clickable sprites,
without interference from regular divs. They are placed in a separate
copy of the regular lzdiv sprite hierarchy so we have more control.
This also provides a place to put focused inputtext divs so they are in
the foreground and clicking/dragging to edit works properly

One reason for this is to ensure clickable areas are always 'on top' of
non-clickable views - see for details.

We discovered we had to use an image for clicking to work properly in IE
- see - IE doesn't
correctly send clicks for nested clickable views with swappable resources

Next, another issue came up in IE (surprise) where text prevented
clickable from working - see

We had to add an explicit clickable div to inputtext to fix - Empty inputtext with
clickable parent can't be selected in IE DHTML

Later, we discovered resources interfered with inputtext clickable - see

> I am unable to reverse-engineer what they are trying to do. I am
> confused by the fact that there are style classes called lzclickdiv and
> lzinputclickdiv, but they are not assigned to the divs named
> __LZclickdiv and __LZinputclickdiv. Why is __LZclickdiv given a class of
> lzdiv,

__LZclickdiv needs to behave as an lzdiv - feel free to add another
style to make this clearer!

and __LZinputclickdiv given a class of lzclickdiv?

__LZinputclickdiv behaves as an lzclickdiv - specifically, it's hidden
(along with other lzclickdivs) when
LzInputTextSprite#__setglobalclickable() is called, which shows/hides
all divs named 'lzclickdiv'. This can happen when an inputtext is
focused, to prevent other clickable divs from interfering (see

In fact, it
> appears that the class lzinputclickdiv is not used?

Again, feel free to use it to be more descriptive. It should behave as
an lzdiv though.

Then we have
> another element, named __LZclick, which is sometimes and image and
> sometimes a div, and is also given the class lzclickdiv.

This is a fix for LPP-2955 - see above.

> Just a few clues would probably help me to move forward on actually
> getting scrolledittext working in DHTML.

Quite a sordid history, no?

Amy Muntz added a comment - 17/Jul/09 07:47 AM
Tucker - please put this at the top of your queue.

P T Withington added a comment - 17/Jul/09 10:58 AM
This is going to be a difficult issue. Basically, SWF has a different model of how clicks pass when a non-clickable element overlaps a clickable one. The kludges we have put in place to emulate SWF (which passes the clicks through to the underlying element) result in the text not being clipped by the overlapping elements. I'm concerned that trying to solve that will just add another layer to this already unpleasant ball of mud. Perhaps we should be reconsidering whether we need to emulate the SWF clickability more than we need the clipping of overlapping views to be accurate?

Henry Minsky added a comment - 17/Jul/09 11:23 AM
It would be thrilling if we could dispense with the whole clickdiv parallel DOM tree.

P T Withington added a comment - 17/Jul/09 01:38 PM
I don't know if we can get rid of the clickdiv parallel DOM tree, unless we are willing to give up emulating the SWF click behavior (where clicks over non-clickable elements pass directly through them to the underlying clickable element).

What I'm wondering though, is if we considered _not_ re-parenting the input-text element to the click div, but instead forwarding the mouse gestures from the click div to the input-text element?

André Bargull added a comment - 17/Jul/09 01:48 PM
Will user text-selection work if you are forwarding the mouse gestures?

P T Withington added a comment - 20/Jul/09 12:17 PM
This file would seem to indicate that my idea of trying to forward mouse events does not work.

P T Withington added a comment - 22/Jul/09 08:45 AM
I'm trying your idea of turning of global clickable when an input text gets selected (and leaving the input element where it is, in the sprite container). I'm making some progress, but getting bizarre effects when I try to mousedown and drag to select in the input element. Instead the whole app scrolls!

P T Withington added a comment - 23/Jul/09 08:25 AM
With help from Max, I seem to have something that is working. Sent for review.

Max Carlson added a comment - 27/Jul/09 06:31 PM
Taking over from Tucker. I've sent out a few more revs, and the change is working better now - including with programatically focused inputtexts and tabbing. The other (thornier) thing I can't figure out is how to deal with views in front of an inputtext. This simple testcase fails - I was able to work around a case with the animated focus brackets preventing text selection by hacking the focusrect class, but this kind of code appears all over webtop:
   <inputtext>Can't select or click because we're covered by another view</inputtext>
   <view width="100%" height="100%" bgcolor="red" opacity=".2"/>

Max Carlson added a comment - 29/Jul/09 11:03 AM
r14398 | max | 2009-07-29 11:02:57 -0700 (Wed, 29 Jul 2009) | 20 lines
Changed paths:
   M /openlaszlo/trunk/WEB-INF/lps/lfc/kernel/dhtml/LzMouseKernel.js
   M /openlaszlo/trunk/WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js

Change 20090728-maxcarlson-L by maxcarlson@Bank on 2009-07-28 17:53:48 PDT
    in /Users/maxcarlson/openlaszlo/trunk-clean

Summary: Size views with no bgcolor or resource to 0x0, add separate tree for context menus

Bugs Fixed: LPP-5447 - DHTML: inputtext and clickable (partial)

Technical Reviewer: ptw
QA Reviewer:

Details: LzSprite - (from ptw's change - Move the canvas hiding from the CSS class style to the canvas div, so removing it just removes the div style (and the div reverts to the class style default). Similarly for controlling visibility on all divs.) Add quirks property for sprite constructor. Add fix_contextmenu and size_blank_to_zero quirks, default to on. When fix_contextmenu quirk is on, build context menu container div called lzcanvascontextdiv that lives under the lzcanvasdiv and lzcanvasclickdiv. Set x and y position, visibility, clipping and z-index of context container, if it exists. Lazily build up context menu div tree when context menu is set. Base __LZclick div on cached width and height values. When size_blank_to_zero quirk is on and there's no bgcolor or source property set (and we're not a textsprite), set the width/height to 0 and set __sizedtozero flag so size can be restored as needed. Set the context menu height/width if needed. Restore div size when bgcolor or source is set to a non-null value. Modify __findParents() to accept an optional second argument - when true, look for parents with a null value. Change __updateClip() to update contextmenu and click container div clip values. Clean up context menu and context menu container divs in destroy(). Cache value passed to setID() so it can be used later.

LzTextSprite - Add istextsprite flag to test for text sprite classes more easily.

LzMouseKernel - If fix_contextmenu quirk is on, hide visible and click div trees so context menu tree can be checked to find the correct context menu to show.

Tests: Testcase attached to LPP-7661 works as before, as does the testcase from Maynard on 23/Feb/09 12:12 PM. This change will make it possible for my recent changeset for LPP-5447 to work with context menus...

Max Carlson added a comment - 29/Jul/09 11:09 AM
Testcase for transparent views with context menus and focus

Max Carlson added a comment - 29/Jul/09 03:39 PM
r14405 | max | 2009-07-29 15:38:19 -0700 (Wed, 29 Jul 2009) | 36 lines
Changed paths:
   M /openlaszlo/trunk/WEB-INF/lps/lfc/kernel/dhtml/LzInputTextSprite.js
   M /openlaszlo/trunk/WEB-INF/lps/lfc/kernel/dhtml/LzMouseKernel.js
   M /openlaszlo/trunk/WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js

Change 20090727-maxcarlson-U by maxcarlson@Bank.local on 2009-07-27 16:21:22 PDT
    in /Users/maxcarlson/openlaszlo/trunk-clean

Summary: UPDATED AGAIN AGAIN: Don't re-parent input text to click tree

Bugs Fixed: LPP-5447 DHTML: inputtext and clickable

Technical Reviewer: ptw (pending)
QA Reviewer: (pending)

   This is based on Tucker's change ( I turned off the dom_breaks_focus quirk for firefox, cleaned up LzMouseKernel to not attempt to re-focus inputtexts when showing the click tree again. I had to resort to the istextsprite hack - ! this instanceof LzTextSprite wasn't working - not sure why :(. Finally, I test the target of global onmousemove events, and if it's not an inputtext and one's showing, I hide it so mouse events work.

The rest of this is ptw's original change note:
   This is just a first pass. It doesn't reparent the input text
   sprite into the click tree, and it turns off the click tree when
   you mouse over in input element. The test case works in Safari,
   and Firefox. I have not tested IE.

   LzSprite: Correct fencepost error in __isMouseOver.

   LzInputTextSprite: Add documentation from Max. Fix init clauses
   that were causing the schema-generator to warn. Remove
   reparenting code, replace with hiding/showing the click tree. Now
   we can just turn the whole click tree on and off, since we are not
   reparenting, which should be much more efficient. Only re-enable
   click tree when we _actually_ leave the bounding box of the input

   Test case from LPP-8334. Also see lpp-5447.lzx attached to the bug and

Max Carlson added a comment - 29/Jul/09 05:00 PM
Reopening due to exceptions in IE

Max Carlson added a comment - 29/Jul/09 05:00 PM
r14407 | max | 2009-07-29 16:59:56 -0700 (Wed, 29 Jul 2009) | 18 lines
Changed paths:
   M /openlaszlo/trunk/WEB-INF/lps/lfc/kernel/dhtml/LzMouseKernel.js
   M /openlaszlo/trunk/WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js

Change 20090729-maxcarlson-i by maxcarlson@Bank on 2009-07-29 16:57:45 PDT
    in /Users/maxcarlson/openlaszlo/trunk-clean

Summary: Fix exceptions in IE DHTML from recent changes

Bugs Fixed: LPP-5477 - DHTML: inputtext and clickable

Technical Reviewer: ptw
QA Reviewer:

Details: LzSprite - Add sensible defaults for _w and _h

LzMouseKernel - Test value of targ more carefully

Tests: LPP-5477 and LPP-7661 now pass in IE DHTML