Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#16789 closed defect (fixed)

dojox.mobile.TabBar in slimTab barType and position absolute is not resizing correctly

Reported by: dg Owned by: Sebastien Brunot
Priority: undecided Milestone: 1.9
Component: DojoX Mobile Version: 1.9.0a2
Keywords: Cc:
Blocked By: Blocking:

Description

TabBar? in slimTab barType and position absolute is not resizing correctly

If the resize is called several time with sometimes the size parameter set and sometimes not, there are strange side effects.

In slimBar type, the resize() method is setting a padding left.

If afterwards, the resize is called with a size parameter, this size is set using setMarginBox. As there's some padding the size will be smaller that the real size.

If after again, the resize is called without the size parameter, as position == absolute the width is get with domGeometry.getContentBox() which returns the wrong size...

Attachments (4)

test_TabBar_resize.html (1.5 KB) - added by dg 7 years ago.
Added reproducing sample (simply resize window)
16789.TabBar.js.patch (408 bytes) - added by dg 7 years ago.
Reset paddingLeft to fixe resize (IBM, CCLA)
MissingLeftPadding.PNG (60.8 KB) - added by Sebastien Brunot 7 years ago.
Regression with 16789.TabBar.js.patch
ticket16789.patch (980 bytes) - added by Sebastien Brunot 7 years ago.
Update TabBar so that the resize method always use the margin box to retrieve dimensions, and set the margin box AFTER setting the padding values for the bar (IBM CCLA).

Download all attachments as: .zip

Change History (16)

Changed 7 years ago by dg

Attachment: test_TabBar_resize.html added

Added reproducing sample (simply resize window)

comment:1 Changed 7 years ago by Eric Durocher

Owner: changed from Eric Durocher to Sebastien Brunot
Status: newassigned

comment:2 Changed 7 years ago by Sebastien Brunot

I've attached a patch that update the resize method of TabBar? so that the margin box is always used to set or retrieve the width of the bar.

comment:3 Changed 7 years ago by Eric Durocher

I would like to be sure we understand exactly why the test that you removed was there in the first place? I can't believe it was there accidentally...

comment:4 Changed 7 years ago by dg

It seems to fixed the simple test case I attached but in real it's furthermore related to dojox.app (because it does some layout itself on "data-constraint"-ned elements). In dojox.app, it's not fixing the issue. To reproduce, edit dojo\dojox\app\tests\longListTestApp\templates\Footer1.html To change the tab bar type in "slimBar" and then launch this application. "dojo\dojox\app\tests\longListTestApp\index.html" To simulate huge size changed (instead of little incremental ones), I'm using a browser extension that allow to set window size. Change the window size from 600x800 to 800x600, for example, to show the problem.

comment:5 Changed 7 years ago by Eric Durocher

OK the first patch does not fix the original problem. Damien investigated more, and it seems the problem is that getMarginBox returns inconsistent results when a padding has been set.

Another solution is to clear left padding at the beginning of the method. Damien has tested that and it fixes his original problem. Sebastien, could you try that and test as much as possible for regressions?

Last edited 7 years ago by Eric Durocher (previous) (diff)

Changed 7 years ago by dg

Attachment: 16789.TabBar.js.patch added

Reset paddingLeft to fixe resize (IBM, CCLA)

comment:6 Changed 7 years ago by Sebastien Brunot

There is a regression with 16789.TabBar?.js.patch: when using fill="always" on a tab bar, the left padding is missing (cf. screenshot). I will look into that.

Changed 7 years ago by Sebastien Brunot

Attachment: MissingLeftPadding.PNG added

Regression with 16789.TabBar.js.patch

comment:7 Changed 7 years ago by Sebastien Brunot

Thjere is a 6px left and right padding defined in the style mblTabBar, hence the regression when setting programmatically the left padding to 0px.

In my opinion we should either:

1) Use my first patch (solves the issue demonstrated in the attached html sample and cause no regressions) and open another ticker for the issue with tab bars in dojox app ; 2) Investigate why getMarginBox returns inconsistent results when a padding has been set and fix the issue in getMarginBox if there is one.

comment:8 Changed 7 years ago by dg

1) Your first patch is not correct when the resize() method is called with a size and then without a size. This is the case in dojox.app use case but it could happen elsewhere. This is a bug of the widget and not of dojox.app. It is highlighted by dojox.app use case.

2) The straightforward patch is then to test fill always before setting the padding to 0 in the resize(). As there's no issue when fill = always no need to set padding to 0.

3) The best solution would have been to completely remove the setting paddingLeft and put a class to center the tabs. I cannot believe that this is the only way to center them... But without changing everything 2) seems to me to be the best.

Changed 7 years ago by Sebastien Brunot

Attachment: ticket16789.patch added

Update TabBar so that the resize method always use the margin box to retrieve dimensions, and set the margin box AFTER setting the padding values for the bar (IBM CCLA).

comment:9 Changed 7 years ago by Sebastien Brunot

I've updated my initial patch to solve the issue with the dojox/app example. The resize method of TabBar now always uses margin box for setting and retrieving width, and it sets the margin box on the bar (when resize is called with a size parameter) only AFTER it has defined the padding values.

Last edited 7 years ago by Sebastien Brunot (previous) (diff)

comment:10 Changed 7 years ago by dg

The proposed patch is also fixing the issue in my use case.

comment:11 Changed 7 years ago by Patrick Ruzand

Resolution: fixed
Status: assignedclosed

In [30869]:

fix TabBar? resize issue, fixes #16789

comment:12 Changed 7 years ago by Patrick Ruzand

Milestone: tbd1.9
Note: See TracTickets for help on using tickets.