Top Margin of element ignored when table within element grows in size

RESOLVED INVALID

Status

()

Core
Layout
RESOLVED INVALID
3 years ago
2 years ago

People

(Reporter: Neil Larson, Unassigned)

Tracking

({testcase-wanted})

43 Branch
testcase-wanted
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [closeme 2016-04-01])

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.0.2526.106 Safari/537.36

Steps to reproduce:

We have a primary page layout of the following 

<body>
    <header></header>
    <section id="sidenav"></section>
    <section id="content"></section>
</body>

The <header> element is 4rem tall and has fixed positioning applied at top:0 left:0
The <section#sidenav> element is 19.1rem wide and has fixed positioning applied at top:4rem left:0
The <section#content> element is allowed to grow to fit the rest of the space and is positioned with margin: 4rem 0 0 19.1rem

For a number of our views (SPA with dynamic rendered templates) we have a table managed by jquery.tablesorter and jquery.tablesorter.pager and the following steps reproduce the following.

1) select view with a table representing a large number of results
2) scroll to the bottom of that view and access the table pager controls
3) select the 'page size' dropdown and select a larger page size
4) scroll back to top of the page and observe the top-margin is no longer respected, the entire <section#content> has moved up the 4rem.


Actual results:

As indicated in Step 4 above, the actual results are that the top portion of the css margin: 4rem 0 0 19.1rem is ignored. 

Additional information:
1) The following conditions were observed. If you 
    A) right click on the content and select "Inspect Element" from the drop-down to open the developer tools
    B) select the <section#content> element to view it's css
    C) select the "margin: 4rem 0 0 19.1rem" rule to uncheck it and then immediately select it again to re-check it, the margin reappears and behaves as expected until you change the table page size again

2) This behavior only occurs when increasing the table page size, not decreasing. This lowers the likelihood of it being a jquery/plugin issue and reinforces the idea its something related to the browser rendering engine

3) This appears to be a browser level issue for the following two reason
    A) This same behavior was NOT seen in IE, Safari, or Chrome
    B) After this issue has been observed (e.g. the steps above were followed) even refreshing the page does not fix it so its something more than mere reloading the page data and css (this is a more intermittent observation as after some time, reloading will reset the page accordingly. This could be a cache issue but I have "cleared everything" in the session and cache settings and reloaded with the same broken results so something browser level appears to be happening)


Expected results:

I would expect that 

1) The top margin to be rendered and respected consistently across views and actions.
2) The refreshing of a page would reset all style and rendering to display this correctly in that context

Comment 1

3 years ago
Could you attach a simple testcase to the bug report, please.
Flags: needinfo?(nlarson)
Keywords: testcase-wanted

Updated

3 years ago
Component: Untriaged → Layout
Product: Firefox → Core
Hi Nail,

Can you please provide a test case like Loic`s suggested in comment 1, so we can try to reproduce this issue? 

Also, can you please test this on the latest Firefox release (44.0.2) or latest Nightly (47.0a1, https://nightly.mozilla.org/) and tell me if this still reproduces for you ? When doing this please use a new fresh Firefox profile, maybe also in safe mode (https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems).

Thanks,
Cosmin
Whiteboard: [closeme 2016-04-01]
(Reporter)

Comment 3

2 years ago
Hi Loic, Cosmin,

My apologies, this fell through the cracks while we were getting a release pushed. We did end up finding this to be an internal issue not a browser issue as we thought. My apologies for not following up. This can be closed. 

Thanks
Neil
Flags: needinfo?(nlarson)
Hi Neil,

Thanks for the reply. Considering this I will close this issue as resolved - invalid.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.