Closed Bug 231338 Opened 19 years ago Closed 19 years ago

Middle-click / middlemouse prefs in Linux/*nix set to false [not set to true]

Categories

(Firefox Build System :: General, defect)

x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: daihardM3, Assigned: benjamin)

References

Details

(Keywords: regression)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040117 Firebird/0.8.0+ (daihard: XFT+GTK2; optimized for P4/SSE-2)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040117 Firebird/0.8.0+ (daihard: XFT+GTK2; optimized for P4/SSE-2)

Middle-clicking anywhere on the scroll bar should cause the scroll button to
jump to that location. It has been working that way with the Linux version of
Mozilla Firebird up to the 2004-01-15 build. However, in my 2004-01-17 build, it
no longer works. Middle-clicking on the scroll bar simply doesn't do anything.

Reproducible: Always

Steps to Reproduce:
1. Start Mozilla Firebird.
2. Middle-click an open area on the scroll bar.
3. See what happens to the scroll button.

Actual Results:  
Nothing happens.

Expected Results:  
The scroll button should have moved to the place which was middle-clicked on.
what is the last nightly that this worked in?
Hi Mike.

Thank you for the response. As far as I can tell, the 2004-01-15 build is the
last nightly where the feature has worked. I did not build a 2004-01-16 nightly;
which means it could have been broken since 01-16 or 01-17. HTH.

Dai
WFM on Windows.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040118
Firebird/0.8.0+ (Oxs G7 SSE optimized)
Confirmed

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040118 Firebird/0.8.0+
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Possibly (or possibly not) related is the fact that middlemouse.contentLoadURL,
middlemouse.scrollbarPosition and middlemouse.paste have all been set to false
quite recently somehow. Setting them [back, I am emphasize *back*] to true fixes
the contentLoadURL problem but not the scrollbar problem, at least for me. I
don't know if it ever worked since I never used it that way.

I'll have to download an earlier build and take a look. Can anyone figure out
what checkins caused the middlemouse prefs to take on Windows rather than Linux
values?
QA Contact: davidpjames
afaik, this was caused by bug 224578.
This should have been fixed by bug 231200.
can someone test today's builds to see if this is true?  the fix landed 
yesterday so current CVS/nightly builds should work fine
No,this hasn't been fixed. My earlier comment was made from a 20040119 build
created following the checkin of the patch for bug 231200.
Setting middlemouse.scrollbarPosition to true works for me on windows after
disabling the All-in-One Gestures extension and restarting Firebird.

The pref is now set in bin/greprefs/all.js. The source location is
mozilla/modules/libpref/scr/init/all.js. That file has "platform-specific
#ifdefs at the end" which "override the generic * entries at the top".
On Linux, bin/greprefs/all.js should contain middlemouse.scrollbarPosition
twice: once set to false at the top (generic), once set to true at the bottom
(platform-specific, should override the former). Please check if you see this in
your bin/greprefs/all.js.

Before the checkin of bug 231200, Firebird's all.js contained that pref as well
and set it to false, thus overriding the platform-specific "true".
This is mine, whether it's a real bug or not. Can I get someone to verify if
this still exists, with a build that fits these criteria:

1) you have a tree updated since 01/18/2004 15:39
2) you have wiped both dist/bin/greprefs/* and dist/bin/defaults/pref/* before
building (or done an ordinary "clean" build)
Assignee: blake → bsmedberg
WFM now.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040119 Firebird/0.8.0+
(daihard: XFT+GTK2; optimized for P4/SSE-2)

I did a clobber build based on the tree I checked out at 4:50 PM (PST).

So it _is_ intended that all.js has been replaced with firebird.js, correct?
> So it _is_ intended that all.js has been replaced with firebird.js, correct?
Sort of. Firebird's old all.js got renamed to firebird.js. In addition to that,
we've now got the application independent all.js. See comment 10 and bug 231200
comment 0.
OK, I'm gonna close this. If you experience this again, feel free to reopen.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → WORKSFORME
v. WFM w/ Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040120
Firebird/0.8.0+

-->Dupe-proofing the summmary
-->build-config

After a clobber build all is now good. This has to be one of the oddest
build-related bugs I've ever seen. Plus middlemouse in the scrollbar is now
working for me as well.

Status: RESOLVED → VERIFIED
Component: General → build-config
Summary: Middle-click on the scroll bar does not move the scroll button → Middle-click / middlemouse prefs in Linux/*nix set to false [not set to true]
*** Bug 231440 has been marked as a duplicate of this bug. ***
Just in case anybody still experiences this problem:

Did you delete the whole MozillaFirebird directory before extracting the newer
build (like you should've done)? If you didn't, you've got the old
MozillaFirebird/defaults/pref/all.js left over from the older build, which
contains those prefs set to false. The file doesn't get overwritten by the new
version, because it's now called firebird.js.
Please erase the whole MozillaFirebird directory and reextract your build into it.
Why does Firebird load all.js when all.js is present, if that file isn't
supposed to exist?
Firebird loads every *.js file in defaults/pref/ and greprefs/.
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.