Closed Bug 204676 Opened 21 years ago Closed 21 years ago

Left Mouse click doesn't load link

Categories

(Core :: DOM: Events, defect)

Product:
Core
Component:
DOM: Events
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: hhschwab, Unassigned)

References

Details

Attachments

(1 file)

disable dependent loading on all but unix
2.67 KB, patch
blizzard
: review+
asa
: approval1.4b+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030506
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030506

When I click on any link, it gets framed, so the mouseclick is recognized, but
it doesn´t load. It loads, when I rightclick on it, open in new tab.


Reproducible: Sometimes

Steps to Reproduce:
1.left click on a link
2.
3.

Actual Results:  
should load, but puts only a dotted line around the clicked link.

Expected Results:  
should load linked page

Saw same behaviour, when I installed todays nightlie for a neighbor, which asked
me yesterday to install him mozilla. Yesterday I installed a version 20030429,
and today I upgraded to current nightlie, without deinstalling.
I´ll retry tomorrow with a fresh profile and deinstalling.
My computer is running Win98 with SP1, and is used to nightlies :-)
my neighbours notebook is running WinME and Netscape4.75, and got its first
newer Browser yesterday, no previous Netscape6, 7 or mozilla.
wasn´t msure about the component, changed to DOM EVENTS because bug 196012 is
DOM EVENTS. Can this bug be a regression from bug 196012?
Bug 196012 crash while hovering over menu - Trunk M130 
[@ nsEventStateManager::DispatchMouseEvent]
Component: DOM HTML → DOM Events
I am seeing the same situation with the 0506 build, Windows 98.  First time the 
program is run after installation, cliking on links works; after exiting, all 
subsequent clicks on links do nothing (except shift the appearance of the link 
to its :active representation).  This is true even if starting the program with 
a different profile.

Same build under Windows 2000 is not exhibiting a problem.

I have installed three times on this system; once with mail/news, twice browser 
only, none of the other components installed at any time.  Each time, I told 
Mozilla not to make itself the default browser.

Requesting Block on 1.4b because this is a doozy.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.4b?
I´ve done Online-Installs, and Upgrade installs.
IIRC I´ve downloaded the 12 MB full installer, and started it from downloadmanager .
Now I deinstalled Mozilla off line, and installed the 2003050604 build into the
old directory, and it is working.
Will retry at work by doing an online/upgrade-install.
Summary: Left Mouse click doesn´t load link → Left Mouse click doesn't load link
At home: deinstalled Build 2003050604, deleted directory, and reinstalled.
As stated in comment #2, it was working after first start, and not working after
next.
At work WIN98SE:
saw today that 2003050604 wasn´t working, made upgrade install Build ID
2003050610 , to no avail.

Raising severity, to get attention.
If this bug doesn´t block release, it should be noted prominently, not only
hidden in the release notes as done with bug 192294.
That bug produced a lot of dupes, and a lot of sore people.
Why should I download, if it is not working?
It should be noted preceding the download link, that this release isn´t working
with Win98, Win98SE, WinME, and supposedly Win95 also.
Severity: major → blocker
did upgrade install to BuildID 2003050509, same error.
did upgrade install to BuildID 2003050211, working.
A good course of action would be to keep downloading builds and narrow the
builds even further.  So far there is a 3 day interval, which has a couple
suspect checkins, but if we could narrow that down to say a 12 hour time period
or something, it would be great.

If comment 5 is correct, then jkeiser's landing of bug 196012 is not the culprit
since it was not checked in until 05/05/2003 17:03 (8 hours after the broken
build was created).
The difference in first and subsequent runs makes me think it's not my checkin.
 Doug, can you think of any way that your checkin for bug 193442 could cause
something like this?

Btw, it's very unlikely that this has anything to do with bug 196012.
to clarify:
just repeated installations, full exes without uninstalling, just
overinstalling, using same directory.

BuildID 2003050509 over BuildID 2003050211, started Bugzilla query BugsToday
from my bugmarks: same error at first start.
BuildID 2003050211 over BuildID 2003050509, instantly working

Didn´t find any normal win32-exes between these dates.
Tried Phoenix, ok
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030504 Mozilla Firebird/0.6

Ah.  I didn't realize we don't produce windows nightlies over the weekend.  That
kind of sucks.

Just curious, but does it work if you do an uninstall first?  I am not sure if
we support installing over existing installs.  Every release notes we include
something like: http://www.mozilla.org/releases/mozilla1.4a/#install

Installation Notes

Install into a new empty directory. Installing on top of previously installed
builds may cause problems.
BuildID 2003050509 installed in empty directory: working
BuildID 2003050509 installed ontop of working 2003050509: working
BuildID 2003050509 installed ontop of 20030506: not working
BuildID 20030506   maybe onetime working after installation in empty directory,
not working thereafter.

so:
BuildID 2003050211, working installed over notworking version
BuildID 2003050509, working installed in empty directory after uninstall.
BuildID 2003050604, not working
to verify that this wasn't my check in you can do this:

after compreg.dat has be created, open it up.  You will see lines under the
"COMPONENTS" section that look like this:


rel:xpc3250.dll,1052146150493,xpcom.dll nspr4.dll plc4.dll plds4.dll js3250.dll


Delete everything after the second comma to the end of the line.  For example,
the above line becomes:

rel:xpc3250.dll,1052146150493


Hi DougT,
seems to be your checkin:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030507
installed in empty directory, started, closed, made copy of compreg.dat

started to verify error, error seen.

deleted compreg.dat, replaced it with edited compreg.dat according to comment #12
started to verify error, now it´s working.
This patch is what I propose doing.  For 1.4, we disable depedent loading since
it basically doesn't work on windows.  This means that dll's dropped into the
system directory may screw up an install of mozilla.  Maybe we can get around
this by setting the cwd to the gre directory (a variation of 202363).

On unix, where we know it works fine, we leave it enabled.  post 1.4, we should
investigate a way to support dependent loading more directly.
OK. Who can give us quick reviews on this? We need to get it in and get respins
ASAP.
Before blasting ahead with the patch: the workaround suggested in Comment 12 is 
not working for my problem system.  I have mail in to DougT checking on a 
detail.
Flags: blocking1.4b? → blocking1.4b+
Comment on attachment 122665 [details] [diff] [review]
disable dependent loading on all but unix

r=blizzard
Attachment #122665 - Flags: review+
Is this ready to land? Mike, what of your email to dougt? 
Comment on attachment 122665 [details] [diff] [review]
disable dependent loading on all but unix

a=asa (on behalf of drivers) for checkin to 1.4b
Attachment #122665 - Flags: approval1.4b+
*** Bug 204747 has been marked as a duplicate of this bug. ***
Fix is in.

Checking in xcDll.cpp;
/cvsroot/mozilla/xpcom/components/xcDll.cpp,v  <--  xcDll.cpp
new revision: 1.70; previous revision: 1.69
done
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Bug 204747 told it works for him after installation of BuildID 2003050708

After deinstalling previous working installation 2003050509, I installed
2003050708 into a new directory,  it doesn´t work for me on Win98 SP1.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030507

Do I have to wait for 2003050804 for testing next working version,
or will there be an earlier file containing the fix?
Hermann, we should have another round of builds available soon. Keep your eyes
on http://komodo.mozilla.org/pub/mozilla/nightly/ for a new dir containing
builds with the fix. 
I think builds with the fix are these
http://komodo.mozilla.org/pub/mozilla/nightly/2003-05-07-12-trunk/  Please give
them a try and let us know if the problem is fixed. Thanks.
*** Bug 204776 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030507
Just installed BuildID 2003050712
This bug seems to be gone, but bug 204770 is very disturbing, because I´ve
organized my bookmarks in 18 visible folders in the personal toolbar, and some
more in the overflow.
Using build http://komodo.mozilla.org/pub/mozilla/nightly/2003-05-07-12-trunk/
on WinMe seems to have fixed my problem since all links appear to work.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030507 [050712]
from the Komodo Nightlies directory is working OK for me w.r.t. this problem.

Regarding Asa's query from comment 18 -- I think you've already heard from Doug, 
but it sounded like the slight difference I saw between his post for a 
workaround and my compreg.dat file was not important.  The workaround did not 
work for my system.

Verifying fix.
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: