ICEmobile
  1. ICEmobile
  2. MOBI-123

Page scrolling erratic in Android container when keyboard active

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.0 Beta
    • Fix Version/s: 1.0 Final
    • Component/s: None
    • Labels:
      None
    • Environment:
      ICEmobile/Android

      Description

      In mobile showcase, if you activate the keyboard for input, and then try to scroll the page, you get flickering and blanking out of the page.

        Activity

        Steve Maryka created issue -
        Hide
        Steve Maryka added a comment -

        This is a known issue with Honeycomb. Scrolling behaves properly with HW acceleration turned on. A preference has been added to android container to toggle HW acceleration on/off. While turning it on solves this problem, HW acceleration displays a number of other idiosyncrasies.

        Show
        Steve Maryka added a comment - This is a known issue with Honeycomb. Scrolling behaves properly with HW acceleration turned on. A preference has been added to android container to toggle HW acceleration on/off. While turning it on solves this problem, HW acceleration displays a number of other idiosyncrasies.
        Steve Maryka made changes -
        Field Original Value New Value
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #27033 Wed Dec 21 17:00:05 MST 2011 judy.guglielmin MOBI-123 revert back panelScroller template and comment known issue in jira
        Files Changed
        Commit graph MODIFY /icemobile/trunk/icemobile/samples/mobileshowcase/src/main/webapp/resources/components/panelScroller.xhtml
        Hide
        Judy Guglielmin added a comment -

        1) placing a setTimeoutFunction int he delayedResizeHandler makes not difference ....here is what I did
        var delayedResizeHandler = function(updates){
        ice.log.debug(ice.log, "IN DELAYEDRESIZEHANDLER");
        setTimeout(function () {
        resizeElementHeight('#

        {cc.id}

        ');
        ice.log.debug(ice.log, 'resize on update ' + window.innerHeight);
        }, 100);
        }
        2) the delayedResizeHandler just duplicates the effort of the resizedElementHeight(elementId) function. but...it just does it once. This:-
        var supportsOrientationChange = "onorientationchange" in window,
        orientationEvent = supportsOrientationChange ? "orientationchange" : "resize";
        registers a listener for every time the browser window changes (you can make this work on desktop, by opening up firebug and changing the window size of the browser console for example). It fires a lot.
        3) mostly was working on browser window without container and noticed that if I initially load mobile showcase, don't do anything except rotate the device, it doesn't resize. If I refresh the page, then it will change dimensions every time I then change the orientation for that view only.....after trying this out several times, I get the xmlParseEntityRef error and have to reboot the server.
        When I comment out the delayedResizeHandler function totally, I can't tab through the fields, but I can turn the android tablet and get the proper resize of the screen.
        Anyways the resize event is being fired every time the container changes size. So when you have a popupmenu opening, that changes the size of the container and it wants to continually change the size of the container with the Android (this is exactly how the desktop browsers treat this event as well when you change the size of the available browser window by making firebug console bigger...the event is continually firing then as well). The iPad is a little smarter and this event only fires when the actual orientation of the device has changed.
        If you JUST want to repaint the screen when an actual orientation change has happened, i think we need to keep variables of the actual page size and when they change by a certain amount (for we can check the width of the screen and ensure it has gone from landscape to portrait or changed by a certain %?), then do the resize. In this way, it won't interfere with the actual behaviour of the panel being used.

        Show
        Judy Guglielmin added a comment - 1) placing a setTimeoutFunction int he delayedResizeHandler makes not difference ....here is what I did var delayedResizeHandler = function(updates){ ice.log.debug(ice.log, "IN DELAYEDRESIZEHANDLER"); setTimeout(function () { resizeElementHeight('# {cc.id} '); ice.log.debug(ice.log, 'resize on update ' + window.innerHeight); }, 100); } 2) the delayedResizeHandler just duplicates the effort of the resizedElementHeight(elementId) function. but...it just does it once. This:- var supportsOrientationChange = "onorientationchange" in window, orientationEvent = supportsOrientationChange ? "orientationchange" : "resize"; registers a listener for every time the browser window changes (you can make this work on desktop, by opening up firebug and changing the window size of the browser console for example). It fires a lot. 3) mostly was working on browser window without container and noticed that if I initially load mobile showcase, don't do anything except rotate the device, it doesn't resize. If I refresh the page, then it will change dimensions every time I then change the orientation for that view only.....after trying this out several times, I get the xmlParseEntityRef error and have to reboot the server. When I comment out the delayedResizeHandler function totally, I can't tab through the fields, but I can turn the android tablet and get the proper resize of the screen. Anyways the resize event is being fired every time the container changes size. So when you have a popupmenu opening, that changes the size of the container and it wants to continually change the size of the container with the Android (this is exactly how the desktop browsers treat this event as well when you change the size of the available browser window by making firebug console bigger...the event is continually firing then as well). The iPad is a little smarter and this event only fires when the actual orientation of the device has changed. If you JUST want to repaint the screen when an actual orientation change has happened, i think we need to keep variables of the actual page size and when they change by a certain amount (for we can check the width of the screen and ensure it has gone from landscape to portrait or changed by a certain %?), then do the resize. In this way, it won't interfere with the actual behaviour of the panel being used.
        Hide
        Judy Guglielmin added a comment -

        this seems to give me the correct return for orientation change:-
        var previousOrientation = 0;
        var checkOrientation = function(){
        if(window.orientation !== previousOrientation){
        previousOrientation = window.orientation;
        ice.log.debug(ice.log, "WINDOW ORIENTATION HAS CHANGED!!");
        alert("orientation has changed!");
        resizeElementHeight('#

        {cc.id}

        ');
        }
        };

        window.addEventListener("resize", checkOrientation, false);
        window.addEventListener("orientationchange", checkOrientation, false);

        ....the only problem is that it doesn't handle resize (which I don't think should apply to mobile devices, but we should probably have for desktop browsers....can you think of any reason why they should be used for mobile devices???
        Anyways, the problem now is that I am not that familiar with composite components and I am only getting one of my scroller panels to change their dimenstion/size (not the menu panel).
        Once this is a component and not a composite component, if the mobile devices don't require a resize, we can just write these scripts based on that.

        This works on the iPad as well as the android tablet (even though the menu is not being resized properly for the android tablet, I suspect it is my lack of knowledge regarding composite components and that iPad is doing it's own thing) for some reason the android is just wrapping the entire block of code into one panel and resizing it whereas the composite component still has 2 scrolling panels on the iPad (strange!).

        Show
        Judy Guglielmin added a comment - this seems to give me the correct return for orientation change:- var previousOrientation = 0; var checkOrientation = function(){ if(window.orientation !== previousOrientation){ previousOrientation = window.orientation; ice.log.debug(ice.log, "WINDOW ORIENTATION HAS CHANGED!!"); alert("orientation has changed!"); resizeElementHeight('# {cc.id} '); } }; window.addEventListener("resize", checkOrientation, false); window.addEventListener("orientationchange", checkOrientation, false); ....the only problem is that it doesn't handle resize (which I don't think should apply to mobile devices, but we should probably have for desktop browsers....can you think of any reason why they should be used for mobile devices??? Anyways, the problem now is that I am not that familiar with composite components and I am only getting one of my scroller panels to change their dimenstion/size (not the menu panel). Once this is a component and not a composite component, if the mobile devices don't require a resize, we can just write these scripts based on that. This works on the iPad as well as the android tablet (even though the menu is not being resized properly for the android tablet, I suspect it is my lack of knowledge regarding composite components and that iPad is doing it's own thing) for some reason the android is just wrapping the entire block of code into one panel and resizing it whereas the composite component still has 2 scrolling panels on the iPad (strange!).
        Steve Maryka made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

          • Assignee:
            Steve Maryka
            Reporter:
            Steve Maryka
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: