No hand cursor over links on Windows 95 and NT4

VERIFIED FIXED in Firebird0.6



17 years ago
16 years ago


(Reporter: wlevine, Assigned: dean_tessman)


Windows 95

Firefox Tracking Flags

(Not tracked)



(2 attachments)



17 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021129 Phoenix/0.4
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.3a) Gecko/20021129 Phoenix/0.4

when i mouse over a link in phoenix with windows 95, the hand mouse icon does
not appear.  the hand shows up fine with my other computer with xp

Reproducible: Always

Steps to Reproduce:
1. go to a web page
2. mouseover a link

Actual Results:  
the mouse icon stays the same

Expected Results:  
the mouse icon should turn to a hand

Comment 1

17 years ago
in case this helps i am using an logitech optical mouse with mouse driver
version 9.60  .  and by the way i did test this with a clean install of phoenix
and a new profile.

Comment 2

17 years ago
*** Bug 182798 has been marked as a duplicate of this bug. ***

Comment 3

17 years ago
Confirming this bug in NT4/SP6 with 20021128 as well as 20021129. It does not
occur with 20021126, so I guess some of the chrome clean-ups that happened after
this date are responsible for this and it only affects win versions without
Active Desktop.

Will, I'd suggest you change severity to "major", because the loss of this
functionality means a major reduction of usability on these platforms.

Comment 4

17 years ago
Another suggestion: please change the word "icon" in the summary to "cursor" and
remove "windows 95" (or add "windows nt") to better reflect what seems to be
actually happening here ;). Sorry for the spam.


17 years ago
Severity: trivial → major
Summary: no hand icon over link in windows 95 → no hand cursor over link

Comment 5

17 years ago
I have the same problem on W95c with all Phoenix nightlies since Nov 27.

Comment 6

17 years ago
Is this same problem happening in recent mozilla nightlies? Or is it phoenix

If it is, bug 56167 might be resurfacing....

Comment 7

17 years ago
only phoenix

Comment 8

17 years ago
Tested with a corresponding Mozilla nightly (2002112908-trunk); everything's
normal there, so this is definitely Phoenix-specific and seems to only affect
win os versions without a system hand cursor.
WFM under W2K with a build from 2002/11/28.
Tried it again with a newer build and a clean install. Still WFM under W2K with
a build from 2002/12/01

Comment 11

17 years ago
WFM with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021201 Phoenix/0.4

Comment 12

17 years ago
So this seems to be a confirmation that this only doesn't work on Win 95 and NT4
without IE4 Active Desktop add-on. Also see the corresponding thread on

Comment 13

17 years ago
Seeing this bug with 11-28-2002 NT4 SP6a too;
Since it has been confirmed by enough "smart" users, I'm marking it as NEW.
Ever confirmed: true
I'm seeing this problem on Windows NT4. Another "smart" user. :)
Updating summary.
Summary: no hand cursor over link → No hand cursor over links on Win95 and WinNT


17 years ago
Target Milestone: --- → Phoenix0.6


17 years ago
Summary: No hand cursor over links on Win95 and WinNT → No hand cursor over links on Windows 95 and NT4

Comment 16

17 years ago
Another confirmation from an NT4 user - build information from about is:
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5.

Comment 17

17 years ago

Comment 18

17 years ago
Did someone checked this on Windows 98? Or is it really just related to Windows
versions without Active Desktop as mentioned in comment #3 or comment #12 ?

Comment 19

17 years ago
WFM on Windows 98 SE

Comment 20

17 years ago
I have NT4 WITH Active Desktop installed and I experience this bug with Phoenix
0.5.  I've noticed that it stalls on whatever the cursor happens to be.  If I
rollover a link coming from text, the cursor remains the 'I', if I rollover from
an image, the cursor is an arrow, if I speedily rollover a link from the window
frame, I'll get a resize-handle.  I don't think this bug has anything to do with
Active Desktop.

Comment 21

17 years ago
travis: does your system have a system hand cursor?

Comment 22

17 years ago
Yes, my system has the hand cursor.  Unless 0.5 uses a different hand cursor? 
The cursor worked as it is supposed to with 0.4.

Comment 23

17 years ago

can I help with more information?

I'm wondering why this bug cannot be fixed. Still sitting here with a Phoenix
nightly from November 2002.

Comment 24

17 years ago
Well, the target milestone for this bug is set to Phoenix 0.6 - so it seems like
we'll have to be patient... :o)

Comment 25

17 years ago
I can confirm this bug under Windows NT4. This problem has, however, only
occured since I installed phoenix 0.5, 0.4 worked fine.

Comment 26

16 years ago
It looks to me like we aren't including the IDC_SELECTANCHOR resource.  Win98,
2K, etc. word because they have a system IDC_HAND resource available.  Win 95
and NT do not.


IDC_SELECTANCHOR is defined in widget/src/build/widget.rc as the
widget/src/build/res/select.cur file.

Comment 27

16 years ago
I just hunted through the EXE and all the DLLs in the phoenix directory and
there are no cursors.  Obviously we don't use any of the others defined in
widget.rc, but we need IDC_SELECTANCHOR.

Comment 28

16 years ago
cc: bryner who's done some Phoenix build work before.  Brian, any idea why this
cursor isn't getting included in the .exe?

Comment 29

16 years ago
IIRC, this bug appeared just after Brian made a major build mod (making Phoenix
a static build ?).

Dean's analysis seems to confirm this.

Comment 30

16 years ago
I was just looking into that.  A lot of people have had problems getting
resources into EXEs, but I haven't found a generic solution (non-C++Builder) yet.

Comment 31

16 years ago
cls, do you know what we need to do to get the cursor resource linked into

Comment 32

16 years ago
For a static build, you'd have to set RESFILE in the phoenix Makefile to point
to widget/src/build/widget.res. 
So, the problem is that for a static phoenix build, we're already setting
RESFILE to splash.res.  Is there an easy way to do multiple resource files?

Comment 34

16 years ago
We're not setting RESFILE to splash.res, we're setting RCINCLUDE to splash.rc. 
As  far as I can tell this does nothing, since there's no splash bitmap in the .exe.

This works, btw.  I added "RESFILE = $(topsrcdir)/widget/src/build/widget.res"
right underneath the RCINCLUDE line in browser/app/, and I've now got
cursors in my phoenix.exe.

Comment 35

16 years ago
OK, obviously I was wrong.  splash.rc defines the application icon, which is
kinda important.

Comment 36

16 years ago
Dean, you're a genius.

Comment 37

16 years ago
Posted patch hackSplinter Review
You can only specify one RESFILE.  If you specify multiples, you get a LNK4059
error (eg. "widget.res : warning LNK4059: splash.res already specified;
additional resource file ignored").  I also was unable to get an RCINCLUDE and
a RESFILE to live in harmony, due to the same error.

This patch just hardcodes the cursor resource that we need into the .exe.  It's
the only way I could get all the resources we need into the static .exe.

Comment 38

16 years ago
Well, thanks to Dean's great work here it looks like we have a solution.  When
can this be checked in?

Comment 39

16 years ago
Comment on attachment 116176 [details] [diff] [review]

If I wrap this in an #IFDEF BUILD_STATIC_LIBS, will the compiler see it or does
only the build process see that?
Right now there's no #define for that, but you could add one to the,


Comment 41

16 years ago
Thanks Brian.  I'll do that and check it in.

Comment 42

16 years ago
Excellent, that did the trick.  Checked in.
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 43

16 years ago
Thanks a lot Dean for your detective work to fix this. I'm looking forward to
downloading the first Phoenix (or whatever) nightly since over two months.

Comment 44

16 years ago
This fix should be in 20020308, shouldn't it? Sadly it still doesn't work for me.

Comment 45

16 years ago
Hrm.  The cursor's definitely in the .exe so it must be something else as well.
 Sorry 'bout that, it's tough to test since I don't have Windows 95 or NT 4.
Resolution: FIXED → ---

Comment 46

16 years ago
OK, nsToolkit::mDLLInstance is going to return 0 because it's set in DLLMain,
which is never called for a static build.

Comment 47

16 years ago
Or I could read the entire source code before spamming everyone.  We set it in
the creator for static builds.

I'll have to do more digging, which means (sigh) that I'll need to build a
static build again.

Comment 48

16 years ago
Assignee: blaker → dean_tessman

Comment 49

16 years ago
This is fixed now.
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 50

16 years ago
Yep, I can confirm this is fixed now with 20020310 on NT4. Thanks again.

Comment 51

16 years ago
Verifying based on lazlo's comment 50.
You need to log in before you can comment on or make changes to this bug.