History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: LPP-4553
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: P0 P0
Assignee: Mamye Kratt
Reporter: Dmitry Kurochkin
Votes: 0
Watchers: 1
Operations

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

basefocusview warnings when canvas size changes

Created: 22/Aug/07 10:43 AM   Updated: 13/Feb/08 12:36 PM
Component/s: Components - base
Affects Version/s: 3.3.3, 4.0.3, 4.0.5WaffleCone
Fix Version/s: RingDing (4.1)

Time Tracking:
Not Specified

File Attachments: 1. File 20070824-Admin-8.tar (30 kb)
2. File lpp-4553.lzx (0.7 kb)
3. File lpp-4553a.lzx (0.3 kb)


Severity: Minor
Fixed in Change#: 6,270
Runtime: N/A
Fix in hand: False


 Description  « Hide
Hi OpenLaszlo developers!

I've found a bug in basefocusview. Both 4.0.3 and 3.3.3 versions are
affected. I've tested swf8 runtime only.

Steps to reproduce:

1. Create application with canvas width and height set to 100%. Compile
it with debug enabled.
2. Set focus to some view.
3. Run LzFocus.clearFocus() in debug window to clear focus.
4. Resize browser window.

Two warnings are printed:

WARNING: base/basefocusview.lzx:234: reference to undefined property 'width'
WARNING: base/basefocusview.lzx:245: reference to undefined property
'height'

The problem is that setTarget method registers followWidth and
followHeight callbacks for canvas onwidth and onheight events.
followWidth and followHeight use target attribute and don't check for
null. But when focus is cleared target is null.

I can not understand this logic. Why we register callbacks for canvas
events but use target width/height in the callbacks? There is a similar
followXY callback for onx and ony events, but it is registered not for
canvas, and is unregistered when focus is cleared. Should not width and
height handling be done in a similar way?

Regards,
 Dmitry

 All   Comments   Work Log   Change History      Sort Order: Ascending order - Click to sort in descending order
André Bargull - 23/Aug/07 01:26 PM
I'm using "LzDelegate#disable()" and "LzDelegate#enable()" instead of "LzDelegate#unregisterAll()" and "LzDelegate#register(..)", because we don't have a public API to determine whether a delegate has registered itself to any events.
(If LPP-4390 was implemented, we could simply call "LzDelegate#register(..)" without reviving LPP-2895.)

"basefocusview#setTarget(..)":
[code]
<!--- @keywords private -->
<method name="setTarget" args="newtarget"> <![CDATA[
    this.target = newtarget;
    if ( !this._xydelegate ) {
        this._xydelegate = new LzDelegate(this, "followXY");
    } else {
        this._xydelegate.unregisterAll();
    }
    
    if (this.target == null) {
        if (this._heightdel) {
            this._heightdel.disable();
        }
        if (this._widthdel) {
            this._widthdel.disable();
        }
        return;
    }

    // make sure that this focusoverlay is aware
    // when the target or any of its parents move.
    var p = newtarget;
    var i = 0;
    while ( p != canvas ) {
        this._xydelegate.register(p, 'onx');
        this._xydelegate.register(p, 'ony');
        p = p.immediateparent;
        i++;
    }

     if ( !this._widthdel ) {
         this._widthdel = new LzDelegate(this, "followWidth", canvas,'onwidth');
     } else {
         this._widthdel.enable();
     }
     if ( !this._heightdel ) {
         this._heightdel = new LzDelegate(this, "followHeight", canvas,'onheight');
     } else {
         this._heightdel.enable();
     }
     followXY();
     followWidth();
     followHeight();
]]> </method>
[/code]

André Bargull - 23/Aug/07 01:32 PM
Simple testcase:

[code]
<canvas debug="true" >
  
  <edittext text="Click Me!" />
  
  <button x="100" text="clear focus" onclick="LzFocus.clearFocus()" />
  
  <handler name="onfocus" args="v" reference="LzFocus" >
    Debug.write("focus-view=%w", v);
  </handler>
  
</canvas>
[/code]

Dmitry Kurochkin - 23/Aug/07 02:26 PM
In 4.0.3 and 3.3.3 setTarget method is different. There is no enable() and disable() calls.
I did not test the code, but I believe it fixes the problem

Which version is this code integrated to?

André Bargull - 23/Aug/07 02:34 PM
"Which version is this code integrated to?"
  > This is just a proposal how to fix this issue, so until now, it isn't integrated in any version.

Dmitry Kurochkin - 23/Aug/07 02:49 PM
I have just tested on 4.0.3 and confirm that it fixes the issue.

André Bargull - 23/Aug/07 05:30 PM
Actually the whole tracking for width/height was broken in basefocusview.
As I neither can svn-review the patch to the svn (authorization failed - warning) nor change this task in any manner (no permission granted), I'll just upload the patch.

André Bargull - 24/Aug/07 12:43 AM
Testcase to show broken tracking:

Steps to reproduce:
1. click on the left button
2. wait a sec -> the left button will resize itself
3. now press tab to focus the right button
4. you can see that the "focusoverlay" still has got the old bounds of the left button, which is wrong, it should have resized itself to the new bounds

[code]
<canvas debug="true" >
  
  <button text="foobar" >
    <handler name="onfocus" >
      LzTimer.addTimer(new LzDelegate(this, "changeBounds"), 1000);
    </handler>
    <method name="changeBounds" >
      this.setWidth(200);
      this.setHeight(400);
    </method>
  </button>
  
  <button x="300" text="blah" />
  
</canvas>
[/code]

Dmitry Kurochkin - 24/Aug/07 01:15 AM
I suspected this. That's why I've asked a question if width/height should be handled in a similar way as x/y.
It looks like the answer is yes. So here is code that does that and it fixes both test cases:

[code]
<method name="setTarget" args="newtarget"> <![CDATA[
    this.target = newtarget;
    if ( !this._xydelegate ) {
        this._xydelegate = new LzDelegate(this, "followXY");
    } else {
        this._xydelegate.unregisterAll();
    }
    if ( !this._widthdel ) {
        this._widthdel = new LzDelegate(this, "followWidth");
    } else {
        this._widthdel.unregisterAll();
    }
    if ( !this._heightdel ) {
        this._heightdel = new LzDelegate(this, "followHeight");
    } else {
        this._heightdel.unregisterAll();
    }
    if ( this.target == null ) return;

    // make sure that this focusoverlay is aware
    // when the target or any of its parents move.
    var p = newtarget;
    var i = 0;
    while ( p != canvas ) {
        this._xydelegate.register(p, 'onx');
        this._xydelegate.register(p, 'ony');
        this._widthdel.register(p, 'onwidth');
        this._heightdel.register(p, 'onheight');
        p = p.immediateparent;
        i++;
    }

    followXY();
    followWidth();
    followHeight();
]]> </method>
[/code]

Dmitry Kurochkin - 24/Aug/07 01:22 AM
Sorry, I did not noticed your patch that does almost the same.
One question: why do you register width/height for newtarget only, but xy delegate is registered to each of its parents?

Dmitry Kurochkin - 24/Aug/07 01:46 AM
Forget it. I have found answer on my question.
Your fix is correct.

Sorry for so much noise.

Regards,
  Dmitry

Amy Muntz - 28/Aug/07 11:49 AM
Fix in Legals for 4.1.

André Bargull - 30/Aug/07 04:10 PM
r6270 | bargull | 2007-08-28 23:36:15 +0200 (Tue, 28 Aug 2007) | 28 lines
Ge?\195?\164nderte Pfade:
   M /openlaszlo/branches/wafflecone/lps/components/base/basefocusview.lzx

Change 20070825-bargull-6 by bargull@dell--p4--2-53 on 2007-08-25 16:48:55
    in /home/Admin/src/svn/openlaszlo/branches/wafflecone
    for http://svn.openlaszlo.org/openlaszlo/branches/wafflecone

Summary: Fixed tracking in basefocusview

New Features:

Bugs Fixed:
LPP-4553 "basefocusview warnings when canvas size changes"

Technical Reviewer: max
QA Reviewer: ben
Doc Reviewer: (pending)

Documentation:
The whole width/height tracking was broken for basefocusview, this is now fixed.

Release Notes:

Details:


Tests:
Two testcases can be found at the bugreport (LPP-4553)

Steve O'Sullivan - 02/Oct/07 09:50 AM
Test script created from notes.

Steve O'Sullivan - 02/Oct/07 09:50 AM
Test script created from notes.

Steve O'Sullivan - 02/Oct/07 10:37 AM
This first group of notes is for text lpp-4553. In this group of notes, please see that both Macintosh DHTML compilations failed. The windows compilations returned errors and/or warnings, but ran and seemed to produce expected results.

DHTML FF W XP SP2 , compiled and returned this warning: ERROR@http://localhost:8080/405/lps/includes/embed-compressed.js#943: dojo.flash.comm has no properties

Notes: Got expected behavior
-----
DHTML IE7 XP SP2, compiled and returned this warning: DEBUG: Source warnings enabledWARNING: testing:0: Test source warning

Notes: Got expected behavior
-----
DHTML Safari 2.0.4 OS X 10.4.10, never completed compilation as far as I could tell. I was stuck at the window that says "Powered by OpenLaszlo." for over 6 minutes by my watch.
-----
DHTML FF 2.0.0.7 OS X 10.4.10, compiled and returned Warnings or Errors:
DEBUG: Source warnings enabledWARNING: testing:0: Test source warning
ERROR @http://localhost:8080/405/lps/includes/embed-compressed.js#943: dojo.flash.comm has no properties

Notes: Left button expands, but there is no focus indicator generated on the screen. Test FAILED.

This next group of notes is for test lpp-4553a.

DHTML FF W XP SP2, compiled and returned Warnings or Errors:
DEBUG: Source warnings enabledWARNING: testing:0: Test source warning
ERROR @http://localhost:8080/405/lps/includes/embed-compressed.js#943: dojo.flash.comm has no properties

Notes: Text in field is top aligned as opposed to center aligned in other tests. Other than that, I got expected behavior.
-----
DHTML IE7 XP SP2, compiled and returned Warnings or Errors: DEBUG: Source warnings enabledWARNING: testing:0: Test source warning

Notes: Text in field is top aligned as opposed to center aligned in other tests. Once I click on the text field the first time and it writes to the debug window, no later clicks are registered by the field. All later clicks to the button DO register and write to the debug window.
-----
DHTML Safari 2.0.4 OS X 10.4.10, App never completes compiling. I am stuck at the window that says "Powered by OpenLaszlo." 6 minutes and counting.
-----
DHTML FF 2.0.0.7 OS X 10.4.10, compiled with these warnings and errors:
DEBUG: Source warnings enabledWARNING: testing:0: Test source warning
ERROR @http://localhost:8080/405/lps/includes/embed-compressed.js#943: dojo.flash.comm has no properties

Notes: Text in field is top aligned as opposed to center aligned in other tests. Other than that, I got expected behavior.

Amy Muntz - 09/Oct/07 12:00 PM
Hi Andre - can you please look into this and submit a fix for trunk (RingDing)? Thanks.

André Bargull - 09/Oct/07 01:06 PM
I haven't got a Mac, so I cannot reproduce any issues under this environment, but as far as I can tell by looking at my submitted patch, compilation shouldn't be influenced in any manner.

Regarding "lpp-4553" - "DHTML FF 2.0.0.7 OS X 10.4.10":
Can you make sure tabbing does change focus by inserting the following handler, because I needed to press two times "tab" to change focus in DHTML Firefox2 XP (DHTML IE6 XP needed only one "tab"-press!).
The handler will print a status message every time focus changes.
[code]
<handler name="onfocus" args="v" reference="LzFocus" >
    Debug.write("focus-view=%w", v);
</handler>
[/code]
So when focus changes, the focus-rect should appear on screen. (Should we file a bug for the denoted focus problem in Firefox2?)

Regarding "lpp-4553a" - "DHTML IE7 XP SP2":
The handler-code prints a status message when focus changes, so pressing multiple times in a row on the editfield won't print every time a message.
Clicking on the editfield, then on the button and finally a last time on the editfield, should give the following output:
[debug]
focus-view=.field
focus-view=«lz.button»
focus-view=null
focus-view=.field
[/debug]
This works for me in DHTML Firefox2, IE6 and Opera9. If this does not work in IE7, it could an indicator that focusing is partially broken for IE7 (at least for LzInputtext). Steve, please verify and if it is necessary, file a bug.

Max Carlson - 09/Oct/07 01:39 PM
LPP-4607 looks to be the Safari issue, because canvas.debug is set to true. That's why you're stuck on "Powered by OpenLaszlo." What build and branch were you running? I'm concerned about the 'dojo.flash.comm' errors.

André Bargull - 19/Nov/07 12:35 PM
Steve, any news for me concerning my last comment?

Amy Muntz - 14/Jan/08 02:28 PM
Mamye - please follow up with both Max and Andre based on the comments in the bug. Thanks.

Max Carlson - 13/Feb/08 12:36 PM
debug now works in Safari.. Didn't test swf8 again...