Closed
Bug 237426
Opened 20 years ago
Closed 20 years ago
JavaScript Slide-In Menus dont slide in
Categories
(Core :: Web Painting, defect, P1)
Core
Web Painting
Tracking
()
RESOLVED
FIXED
People
(Reporter: stadli, Assigned: roc)
References
()
Details
(Keywords: regression)
Attachments
(2 files)
1.36 KB,
text/html
|
Details | |
1.13 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
asa
:
approval1.7+
|
Details | Diff | Splinter Review |
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.
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•20 years ago
|
Assignee: firefox → english-us
Component: General → English US
Product: Firefox → Tech Evangelism
QA Contact: english-us
Reporter | ||
Comment 2•20 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
Reporter | ||
Comment 4•20 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 ?
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.
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•20 years ago
|
Component: English US → DOM
Product: Tech Evangelism → Browser
Version: unspecified → Trunk
Reporter | ||
Comment 7•20 years ago
|
||
Changing Product and Component to Browser and DOM, since this isn't Tech Evangelism AFAICS.
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?).
Comment 9•20 years ago
|
||
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
Assignee | ||
Comment 10•20 years ago
|
||
This fixes it ... we want to copy the old clip area *before* we overwrite it with the new clip area :-)
Assignee | ||
Comment 11•20 years ago
|
||
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+
Assignee | ||
Comment 12•20 years ago
|
||
Comment on attachment 144085 [details] [diff] [review] fix layout regression, simple fix
Attachment #144085 -
Flags: approval1.7?
Reporter | ||
Updated•20 years ago
|
Comment 13•20 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+
Assignee | ||
Updated•20 years ago
|
Priority: -- → P1
Assignee | ||
Comment 14•20 years ago
|
||
checked in
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 15•20 years ago
|
||
*** Bug 237447 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Flags: blocking1.7?
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
You need to log in
before you can comment on or make changes to this bug.
Description
•