JavaScript Slide-In Menus dont slide in

RESOLVED FIXED

Status

()

Core
Layout: View Rendering
P1
major
RESOLVED FIXED
14 years ago
14 years ago

People

(Reporter: Christian Stadler, Assigned: roc)

Tracking

({regression})

Trunk
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040313 Firefox/0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040313 Firefox/0.8

If you visit the URL and click on Search, you'll see a menu popping in instead
of sliding in, what it did at least up to the latest release (Firefox 0.8).

As a side note: If you visit http://ragnarok.gamesurf.tiscali.de/forum/ and
click on one of the arrows next to the forums, only the upper left edge of the
menu appears. This worked fine with the lastest release as well.

Reproducible: Always
Steps to Reproduce:
1. Visit the URL
2. Click on search

Actual Results:  
A small search form pops in.

Expected Results:  
The search form slides in.

Comment 1

14 years ago
The site uses IE/Windows specific code to do the sliding effect in the script
file at http://ragnarok.gamesurf.tiscali.de/forum/clientscript/vbulletin_menu.js.

So this isn't a Firefox bug (though I suppose it could be moved to Tech Evangelism).

Updated

14 years ago
Assignee: firefox → english-us
Component: General → English US
Product: Firefox → Tech Evangelism
QA Contact: english-us
(Reporter)

Comment 2

14 years ago
I tend to disagree, since this worked fine with older (release) builds. Why and
where has this been removed or changed?

PS: The original code lies at
http://www.vbulletin.com/forum/clientscript/vbulletin_menu.js

Comment 3

14 years ago
Which builds?
(Reporter)

Comment 4

14 years ago
The latest release for example (Firefox 0.8 Final):
UA: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206
Firefox/0.8
Download:
http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/0.8/FirefoxSetup-0.8.exe

as well as all builds (including nightlies) that were release prior to Firefox
0.8 Final AFAIR.

As for Mozilla:
It worked with Mozilla 1.7a:
UA: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040219
Download:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7a/mozilla-win32-1.7a-installer.exe

But it didn't with todays nightly:
UA: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040314
Download:
http://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/latest-trunk/mozilla-win32-installer.exe

-> Browser / DOM ?

Comment 5

14 years ago
Created attachment 143984 [details]
Reduced-ish Testcase

You're absolutely right, on 0.8 it works same as IE (that'll teach me to jump
to conclusions based on some misleading comments coupled with IE-specific
code). Here's a reduced testcase, it looks like some sort of painting issue
(maybe do to with clip?), if you press the button then open two tabs and switch
between them the grey square seems to jump in size at each switch.

Comment 6

14 years ago
The regression happened sometime between the nightly builds from 2004-03-10 and
2004-03-11, the only two rendering checkins I can see in that timeframe are Bug
232469 and Bug 232838.
(Reporter)

Updated

14 years ago
Component: English US → DOM
Product: Tech Evangelism → Browser
Version: unspecified → Trunk
(Reporter)

Comment 7

14 years ago
Changing Product and Component to Browser and DOM, since this isn't Tech
Evangelism AFAICS.

Comment 8

14 years ago
Backing out the changes from Bug 232469 and then doing "make" from the top
mozilla dir fixes this behaviour (I don't know what the minimum amount of
make-ing I could have done here is?).
To views.  Even changing the timeout to 100ms doesn't help much -- I only see us
paint one intermediate step.  It's almost like we're no longer invalidating on
clip changes...
Assignee: english-us → roc
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: DOM → Layout: View Rendering
Ever confirmed: true
Flags: blocking1.7?
Keywords: regression
QA Contact: english-us → ian
Created attachment 144085 [details] [diff] [review]
fix

This fixes it ... we want to copy the old clip area *before* we overwrite it
with the new clip area :-)
Comment on attachment 144085 [details] [diff] [review]
fix

very simple regression fix :-)
Attachment #144085 - Flags: superreview?(dbaron)
Attachment #144085 - Flags: review?(dbaron)
Attachment #144085 - Flags: superreview?(dbaron)
Attachment #144085 - Flags: superreview+
Attachment #144085 - Flags: review?(dbaron)
Attachment #144085 - Flags: review+
Comment on attachment 144085 [details] [diff] [review]
fix

layout regression, simple fix
Attachment #144085 - Flags: approval1.7?

Comment 13

14 years ago
Comment on attachment 144085 [details] [diff] [review]
fix

a=asa (on behalf of drivers) for checkin to 1.7
Attachment #144085 - Flags: approval1.7? → approval1.7+
Priority: -- → P1
checked in
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 15

14 years ago
*** Bug 237447 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Flags: blocking1.7?
You need to log in before you can comment on or make changes to this bug.