|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Dr Senior - 13/Feb/08 04:06 AM
Begging pardon... I forgot to mention that the problem only arises compiling to DHTML
reproduced in trunk rev. #8005 in IE6 and IE7 (DHTML)
notes for reproducing: - go directly to the 3rd tabelement (labeled "Four") - click on the btn - cannot click again on the btn - clicking everywhere expect from the inputtext won't restore btn-click behaviour (and except from changing the tabelement..) - however, if you click on the inputtext, the button becomes clickable again Other: user's note that you cannot mark the inputtext couldn't be reproduced Interesting, clicking on the inputtext does *not* make the button clickable again for us.
Also, are you aware than closing and then re-opening the tab will tend to make the button clickable, *so long as the mouse has not triggered any events on the inputtext*. >Interesting, clicking on the inputtext does *not* make the button clickable again for us.
Which OL-version are you using? More fun in IE7: When start the app, go directly to the 3rd tab and click on the btn, IE will crash (but I must be quite fast to accomplish this and it doesn't happen always, argh) We've only just started looking into using the DHTML runtime professionally, and unfortunately, are finding some behaviours which for us are disasterous.
I suspect our "enemy number one" may be related to the bug we're discussing... but I'm not sure if it is or should be opened as a new issue. In a nutshell, it will be common for people to try to layer additional flash based applications over DHTML pages generated in OL. The nightmare (yet another) in Internet Exploder is that these applications *stop receiving mouse input* when placed on DHTML pages generated by OL in IE 7. It is possible to position the mouse in one position and click several times to trigger events in the overlayed application, but *the moment the mouse moves* then something (OL) starts greedily capturing all the events. This has something to do with the core of OL, not any of its components. Is this a known problem? Should I report this seperately, or should it just be treated as something which may be relevant to this issue and should be explored? >Should I report this seperately, or should it just be treated as something which may be relevant to this issue and should be explored?
It'd be great, if you open a separate task to investigate this defect, at best with a small testcase, thanks! r9811 | max | 2008-06-19 15:42:34 -0700 (Thu, 19 Jun 2008) | 16 lines
Changed paths: M /openlaszlo/trunk/WEB-INF/lps/lfc/kernel/dhtml/LzSprite.js Change 20080619-maxcarlson-F by maxcarlson@Roboto on 2008-06-19 15:02:25 PDT in /Users/maxcarlson/openlaszlo/trunk-clean for http://svn.openlaszlo.org/openlaszlo/trunk Summary: Prevent mouse from being locked off in IE Bugs Fixed: Technical Reviewer: promanik QA Reviewer: a.bargull@intensis.de Details: Enable global mouse events whenever the master app div is moused over. Tests: See abargull's instructions in |
||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
P0
Incompatibilities between inputtext and tabelement in IE