Closed Bug 550882 Opened 12 years ago Closed 12 years ago

Setting overflow=hidden and then overflow=visible using script we get no scrollbars back

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking1.9.2 --- .7+
status1.9.2 --- .7-fixed

People

(Reporter: alice0775, Assigned: bzbarsky)

References

Details

(Keywords: regression)

Attachments

(2 files)

Attached file testcase
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100307 Namoroka/3.6.2pre ID:20100307043156
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100307 Namoroka/3.6.2pre ID:20100307043156

Setting overflow=hidden and then overflow=visible using script we get no scrollbars back.
Original report is http://forums.mozillazine.org/viewtopic.php?f=9&t=1781275 

Firefox3.0.x and 3.5.x work well.
But Firefox 3.6.0 and Minefield 3.7a3pre fails.

Is the change of this behavior the intention of the developer?
or something regression?

Steps to Reproduce:
1. Open testcase
2. Click "overflow:visible" button
3. 

Actual Results:
 no scrollbars appear.

Expected Results:
 scrollbars should appear.

regression window:

works:
http://hg.mozilla.org/mozilla-central/rev/02f8bf10f441
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090722 Namoroka/3.6a1pre ID:20090722042136

fails:
http://hg.mozilla.org/mozilla-central/rev/d783d91beec5
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090723 Namoroka/3.6a1pre ID:20090723043404

pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=02f8bf10f441&tochange=d783d91beec5

There is same issue on latest trunk nightly.
Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a3pre) Gecko/20100307 Minefield/3.7a3pre ID:20100307041909

oter browsers:
Firefox 3.0.x and 3.5.x:  works as expected.
Opera 10.50: works as expected.
Google chrome 4.0.249.89: after step 2, resoze window then  scrollbars appear.
Safari 4.0.4:  after step 2, resoze window then  scrollbars appear.
IE8: as same as Firefox3.6.x
Sorry, I revised spelling.  
s/oter/other/ s/resoze/resize/g

other browsers:
Firefox 3.0.x and 3.5.x:  works as expected.
Opera 10.50: works as expected.
Google chrome 4.0.249.89: after step 2, resize window then  scrollbars appear.
Safari 4.0.4:  after step 2, resize window then  scrollbars appear.
IE8: as same as Firefox3.6.x
Looks like a regression from bug 502447, which is pretty odd.  Looking into this now.
Assignee: nobody → bzbarsky
Blocks: 502447
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 7 → All
Hardware: x86 → All
Version: 1.9.2 Branch → Trunk
So what used to happen in this testcase before the fix for bug 502447 landed is that when we constructed the root scrollframe we didn't see the overflow:hidden and hence gave it scrollbars.  Then at layout time we saw they should be hidden and didn't show them.

With the patch for bug 502447 we now see the body styling during the root frame construction and therefore don't create scrollbars at all.  Then at layout time we might want to show them, but they're just not there.
Attached patch This fixes it.Splinter Review
Attachment #431182 - Flags: review?(roc)
Pushed http://hg.mozilla.org/mozilla-central/rev/c7c0db9074c7
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Comment on attachment 431182 [details] [diff] [review]
This fixes it.

Should probably get this in on branch too.  Not sure we need this for 1.9.2.2, though.
Attachment #431182 - Flags: approval1.9.2.3?
This was backed out on suspicion of causing a Tsunspider regression.  Backing out this patch and bug 503832 did fix that regression, an I just relanded this patch as http://hg.mozilla.org/mozilla-central/rev/f0239b3789d9 to try to narrow down which of the two is responsible for the slowdown.
And backed out again; it definitely causes the Tsspider regression.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Duplicate of this bug: 552985
I relanded as http://hg.mozilla.org/mozilla-central/rev/b3367021d661 a few days ago with an attempt to make the code flow identical with and without the patch ... and it _still_ regressed Tsspider.  Since then Tsspider has been updated to not measure pageload anymore, so I just pushed http://hg.mozilla.org/mozilla-central/rev/23e09c2ded59 to remove the hackery.  Calling this fixed.
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
blocking1.9.2: --- → ?
Duplicate of this bug: 564250
blocking1.9.2: ? → ---
Christian, this is a somewhat serious web compat regresion that's been waiting on approval for over a month now...  I understand not wanting to block on it, but can we just get it checked in on the branch?
I think we should block on it; it's a regression of pretty basic functionality.
blocking1.9.2: --- → ?
This is too late for 1.9.2.4. We'll take this in 1.9.2.5
blocking1.9.2: ? → .5+
Keywords: regression
Attachment #431182 - Flags: approval1.9.2.5?
Attachment #431182 - Flags: approval1.9.2.5?
Attachment #431182 - Flags: approval1.9.2.5?
Comment on attachment 431182 [details] [diff] [review]
This fixes it.

Approved for 1.9.2.5, a=dveditz for release-drivers
Attachment #431182 - Flags: approval1.9.2.5?
Attachment #431182 - Flags: approval1.9.2.5+
Attachment #431182 - Flags: approval1.9.2.4?
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/cc47b92e73d8

I hope setting this as fixed1.9.2.6 is the right thing to do.
blocking1.9.2: .5+ → .6+
Attachment #431182 - Flags: approval1.9.2.5+ → approval1.9.2.6+
Depends on: 581240
Depends on: 581336
Depends on: 624425
No longer depends on: 624425
You need to log in before you can comment on or make changes to this bug.