Closed Bug 182695 Opened 22 years ago Closed 21 years ago

No hand cursor over links on Windows 95 and NT4

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Platform:
x86
Windows 95
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED FIXED
Milestone:
Firebird0.6

People

(Reporter: wlevine, Assigned: deanis74)

References

Details

Attachments

(2 files)

Additional related behavior
577 bytes, text/plain
Details
hack
578 bytes, patch
Details | Diff | Splinter Review 
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
3.

Actual Results:  
the mouse icon stays the same

Expected Results:  
the mouse icon should turn to a hand
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.
*** Bug 182798 has been marked as a duplicate of this bug. ***
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.
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.
Severity: trivial → major
Summary: no hand icon over link in windows 95 → no hand cursor over link
I have the same problem on W95c with all Phoenix nightlies since Nov 27.
Is this same problem happening in recent mozilla nightlies? Or is it phoenix
specific?

If it is, bug 56167 might be resurfacing....
only phoenix
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
WFM with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021201 Phoenix/0.4
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
MozillaZine: http://www.mozillazine.org/forums/viewtopic.php?t=1572
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.
Status: UNCONFIRMED → 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
Target Milestone: --- → Phoenix0.6
Summary: No hand cursor over links on Win95 and WinNT → No hand cursor over links on Windows 95 and NT4
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.

    
    

    
  
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 ?

    
    

    
  
WFM on Windows 98 SE

    
    

    
  
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.

    
    

    
  
travis: does your system have a system hand cursor?

    
    

    
  
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.

    
    

    
  
Hello,

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.

    
    

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

    
    

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

    
    

    
  
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.

See http://lxr.mozilla.org/mozilla/source/widget/src/windows/nsWindow.cpp#2472

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

    
    

    
  
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.

    
    

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

    
    

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

Dean's analysis seems to confirm this.

    
    

    
  
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.

    
    

    
  
cls, do you know what we need to do to get the cursor resource linked into
phoenix.exe?

    
    

    
  
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?

    
    

    
  
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/Makefile.in, and I've now got
cursors in my phoenix.exe.


    
    

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

    
    

    
  
Dean, you're a genius.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        hack
        — 
          — Splinter 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.

    
    

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

    
    

    
  
Comment on attachment 116176 [details] [diff] [review]
hack

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 Makefile.in,
i.e.:

ifdef BUILD_STATIC_LIBS
RCFLAGS += -DMOZ_STATIC_BUILD
endif


    
    

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

    
    

    
  
Excellent, that did the trick.  Checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED

    
    

    
  
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.

    
    

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

    
    

    
  
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

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

    
    

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

http://lxr.mozilla.org/seamonkey/source/widget/src/windows/nsToolkit.cpp#551

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

    
    

    
  
mine
Assignee: blaker → dean_tessman
Status: REOPENED → NEW

    
    

    
  
This is fixed now.
Status: NEW → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED

    
    

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

    
    

    
  
Verifying based on lazlo's comment 50.
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: