Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#16681 closed defect (fixed)

Layout and transition problems when using both application and view fixed bars for a ScrollingView

Reported by: Sebastien Brunot Owned by: Eric Durocher
Priority: undecided Milestone: 1.9
Component: DojoX Mobile Version: 1.8.3
Keywords: Cc:
Blocked By: Blocking:

Description

See the attached sample html file and the attached pictures: they are layout issues when a page defines application wide fixed bars (header and footer) and also define a ScrollingView? that contains its own header and footer. The problems are different with declarative and programmatic views (see the attached pictures). There is also a problem during the transition between the two views (transition duration set to 5 seconds in the example file to demonstrate it more clearly), as the in view is not placed below the application bar.

Attachments (5)

ticket.html (3.9 KB) - added by Sebastien Brunot 9 years ago.
sample file that demonstrate the problem
appAndViewBars1.PNG (24.1 KB) - added by Sebastien Brunot 9 years ago.
layout with the declarative view
appAndViewBars2.PNG (23.6 KB) - added by Sebastien Brunot 9 years ago.
layout with the programmatic view
ticket16681.patch (11.0 KB) - added by Sebastien Brunot 9 years ago.
Proposed fix + doh test (IBM CCLA)
ticket16681-complement.patch (801 bytes) - added by Sebastien Brunot 9 years ago.
Fix the side effect of the first patch (app footer not taken into account to define the height of the scrollable area). (IBM CCLA)

Download all attachments as: .zip

Change History (15)

Changed 9 years ago by Sebastien Brunot

Attachment: ticket.html added

sample file that demonstrate the problem

Changed 9 years ago by Sebastien Brunot

Attachment: appAndViewBars1.PNG added

layout with the declarative view

Changed 9 years ago by Sebastien Brunot

Attachment: appAndViewBars2.PNG added

layout with the programmatic view

comment:1 Changed 9 years ago by Sebastien Brunot

Working on a fix.

comment:2 Changed 9 years ago by Sebastien Brunot

I've attached a patch that fix the problems and define a doh test. The fix has two parts:

1) The layout problem is fixed by making sure that both the local and application wide footers are taken into account to perform the layout

2) The transition problem is fixed by making sure that the padding top is added to the domNode of a ScrollableView? instead of being added to the contentNode (as it is for other views).

Version 0, edited 9 years ago by Sebastien Brunot (next)

comment:3 Changed 9 years ago by Sebastien Brunot

Final version of the patch has been attached, after verification of non regression.

comment:4 Changed 9 years ago by cjolif

Milestone: tbd1.9

Changed 9 years ago by Sebastien Brunot

Attachment: ticket16681.patch added

Proposed fix + doh test (IBM CCLA)

comment:5 Changed 9 years ago by cjolif

Resolution: fixed
Status: newclosed

In [30572]:

fixes #16681. Fixes layout and transition problems when using both application and view fixed bars for a ScrollingView. Thanks Sebastien Brunot (IBM, CCLA). !strict.

comment:6 Changed 9 years ago by cjolif

In [30573]:

refs #16681. Add the test to the list. Thanks Sebastien Brunot (IBM, CCLA).

comment:7 Changed 9 years ago by Sebastien Brunot

The first patch has a side effect: when there is an application footbar, it size is not taken into account to define the height of the scrollable area. As a consequence, the bottom of the scrollable area is below the footer.

I'm attaching a second patch, that complement the first one, to fix this side effect.

Changed 9 years ago by Sebastien Brunot

Fix the side effect of the first patch (app footer not taken into account to define the height of the scrollable area). (IBM CCLA)

comment:8 Changed 9 years ago by cjolif

Resolution: fixed
Status: closedreopened

comment:9 Changed 9 years ago by cjolif

Resolution: fixed
Status: reopenedclosed

In [30623]:

fixes #16681. Fix a regression introduced by #16681 (app footer not taken into account to define the height of the scrollable area). Thanks Sebastien Brunot (IBM CCLA). !strict.

comment:10 Changed 9 years ago by ben hockey

In [30657]:

remove trailing comma introduced in r30572

refs #16681 fixes #16745

Note: See TracTickets for help on using tickets.