Closed Bug 173773 Opened 23 years ago Closed 22 years ago

CSS a:link definition not recognized when page is first opened.

Categories

(Camino Graveyard :: Page Layout, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: emanuel_ravelli, Assigned: bryner)

References

()

Details

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021010 Chimera/0.5+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.0.1) Gecko/20021010 Chimera/0.5+ Navigator doesn't respond to the CSS a:link defintion located on an external CSS file. Does respond when the navbar is clicked on or the page is loaded in cache. Code on CSS page is as fllows: a:link { color: maroon; background: transparent; background-color: transparent; } a:visited { color: #550055; background: transparent; background-color: transparent; } a:hover { color: #880088; background: transparent; background-color: transparent; } Reproducible: Always Steps to Reproduce: 1. Open <http://www.pullingrank.com/>. 2. Roll the curser over the navbar at left. Text should change to maroon. 3. Click anywhere on navbar; CSS a:link definition will work. Actual Results: CSS a:link definition will work. Expected Results: CSS a:link definition should work immediately on loading the page for the first time.
> Click anywhere on navbar; CSS a:link definition will work. Is this a Chimera-only problem? I don't see that in Mozilla... Note that there is nothing in that navbar to be affected by "color" -- those are all images, not text.
>Is this a Chimera-only problem? I don't see that in Mozilla... You are correct. This is a Chimera problem only. All other browsers (Mac and Windows) function correctly. >Note that there is nothing in that navbar to be affected by "color" -- those are >all images, not text. My error. You are correct again: these ARE images (I hate growing old). This has occurred before with other sites. Chimera will not load images as instructed with JavaScript when a page is first opened. Again, the JavaScript works correctly with all other browsers on two platforms. Sorry for the original reporting error.
This sounds similar to my bug 172649.
Sorry, given that we discovered that this is an inability render JavaScript rollover correctly, I don't see the connection to bug 172649. But I'm no techical wizard. The point that bothers me is that even if the JavaScript is lousy, All browsers on all platforms can handle the rollovers correctly, but Chimera cannot.
WorksForMe using Chimera/2002100304 on 10.1.5. Text at left becomes maroon on mouseover.
Works for me Chimera/2002101004 using 10.2 ONLY after clicking somewhere in the navbar; this seems to load the necessary files. Once the files are loaded, the rollovers work.
Now THIS is fascinating: when I first pull up a page, rollovers don't function. If I click ANYWHERE on the open browser window (including the title bar), the rollovers then work. This problem was happening in all versions of Chimera, but this is the first time I've ever notice that it doesn't matter where one clicks on the page. Mystery inside a mystery.
More and more interesting. This lack of recognition of JavaScript rollovers is happening in all versions of Chimera (and ONLY Chimera) and all Web pages with such scripting. Again, once one clicks anywhere on the page, the problem self-remedies.
Still WorksForMe using Chimera/2002100304 on 10.1.5, without clicking anywhere first.
Mr. Kolanek, Here's what I've done to isolate the problem. 1. Completely deleted all Chimera-related files. 2. Reformatted my entire hard drive and reinstalled 10.2.1. 3. Downloaded and reinstalled Chimera. Results: exactly the same. Conclusion: Since the pages load correctly with IE, OmniWeb, Mozilla, Opera, yadda, yadda, yadda; that it's reproducible; and whether it is a software conflict or not, using Ockham's Razor I can only conclude that this is a Chimera bug. The question is what can we do about it. I'm open to suggestions. If requested, I'll do another OS X clean install--because I'm a masochist. I see Chimera as the future and want to ensure its success. Thank you for your time and help.
Called Apple and got the usual "reinstall the OS." They think this may be caused by a software conflict. I assume that this can only be so if another program is running and have deleted and reinstalled programs that run behind the scenes without success. Could there be a conflict with an non-running application? Should other browsers be deleted, e.g., Mozilla, OmniWeb, yadda, yadda, yadda?
Emanuel, OS reinstallation and disk reformatting are far, far too extreme. They're useful only for you to try to get the software working the way you want than to help Chimera's developers figure out why it's happening, which is what bugs like this are for.
Greg, you've made the happiest man on earth! The thought of reinstalling the OS--yet again--makes me want to move to Windows. FYI, I simultaneously eliminated all the user-enabled startup items this morning. No success. They were: Transport Monitor MagicMenu.menu Microsoft Database Daemon LCCDaemon Grammarian X So, we at least know that none of these programs are causing this issue.
I can use Apple System Profiler to create a profile of my computer, if that will be of any help. Please let me know.
Emanuel, try creating a new OS X user profile and test Chimera using that. (It will facilitate testing using a different Chimera profile file set.)
Greg, Created a new profile. Lanuched Chimera. JavaScript rollovers worked at startup without the need to click on the page. I'll be... I've completely deleted all the Chimera-related files in the past and reinstalled Chimera. I still had this JavaScript rollover error. But this is interesting. Now what?
Deleted ALL Chimera/Navigator files and folders within current (old) User. Launched Chimera. Created a new profile. JavaScript rollovers did NOT function at startup without clicking somewhere on the page or reloading. The difference here is having not created a new User in OS X, only a new Chimera profile in the old User.
I can't repro this; they work fine for me.
WFM 2003012707
I'm inclined to resolve as WFM based on multiple WFM reports, no found dupes, and age of reporters build. Emanuel, have you seen this in more recent builds (0.60 or a nighlty)?
Chris, I haven't seen this problem in subsequent builds. Thank you for following up. E. Ravelli
Emanuel, thanks for the reply.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.