58651 - Missing the "GO button" on the navigation toolbar

Status: VERIFIED WORKSFORME

(SeaMonkey :: Preferences, defect, P3)

Description

[Patty Mac]

Platform: (Mac, windows, and linux; 2000-10-30-09-MN6).

Steps to reproduce:

1. Launch Netscape 6.
2. Type this url: http://jimbob/jars/f_skin_egypt.html
3. Go to Edit/Preferences/Navigator
Note: Select the "GO" button in the toolbars. That button does not 
appear in the navigation toolbar. I think this problem does not occur
in classic and modern skins so this might go to skinability. Correct me
if I'm wrong, Paul!

Comment 1

[Blake Ross]

I don't see what I can do here.  I don't have the egypt skin nor have I ever 
heard of it, and the link is internal.

This isn't a skin switching bug because it doesn't involve skin switching.  If 
anything, it would go to themes because it's a theme-dependent issue, but it 
probably doesn't belong in Bugzilla at all if it isn't inherently related to 
Mozilla.  (The Themes component is for Modern and Classic bugs only).

Comment 2

[Ben Goodger (use ben at mozilla dot org for email)]

I agree with blake. We should not track bugs in themes other than the ones we 
provide. If we do want to do that (!) then bugs relating to Netscape specific 
themes should be tracked in bugscape. 

Comment 3

[hangas]

returning to pmac, this needs to be assigned to the owner of this egypt skin.

Comment 4

[Patty Mac]

Since I found out that egypt skin (third party skin) is no longer valid to test 
from Todd Pringle yesterday afternoon, therefore, this bug is invalid.

Comment 5

[Patty Mac]

Marking verified

Comment 6

[Peter Trudelle]

Reopening, making summary less specific. My wife is seeing this exact same
problem using 6.2, Modern, on MacOS 8.6. Tried closing and reopening window,
quitting and relaunching browser.  Go button does not appear.

Comment 7

[Boris Zbarsky [:bzbarsky]]

*** Bug 117019 has been marked as a duplicate of this bug. ***

Comment 8

[[not reading bugmail]]

Peter I just started noticing this in today's 3-8-03 build on w2k, didn't really
notice this before today.  Its like the 'go' button doesn't remember preference
settings.  Classic skin.

Comment 9

[Peter Trudelle]

->prefs

Comment 10

[[not reading bugmail]]

I'm seeing this behavior: QL is not running, I'm not using -P <profilename> either.

a) I loaded up 3-9 build, new profile directory and build directory. 
b) started mozilla -> preferences > check 'go' unchecked 'home' 'search' 'print'
c) close pref panel
d) notice 'go' button gets added.
e) close mozilla by either 'x' or Exit
f) start mozilla again
g) 'Go' button is not on the toolbar
h) open preferences panel, 'Go' is checked still.

its doesn't read that option from the file, or is no longer getting written to
the file on close.

Comment 11

[[not reading bugmail]]

I see there is one change to my reproducable steps:

If you follow my testcase above:

on the 2nd time you open mozilla 'Go' button will show up, 

You have to open mozilla a *3rd* time to see this on using a new profile, new
build directory.

subsequent times after this:

if you uncheck 'Go' > hit ok, open preferences > check 'Go' ok.. it will show up
in Toolbar.  close mozilla.  open mozilla, 'Go' is not on toolbar.


I tried to delete XUL.mfl but this didn't affect it.

------------------

build 3-6 works fine. build 3-7, 3-8, 3-9 w2k platform has the problem here.

Checkins to module SeaMonkeyAll between 03/06/2002 08:00 and 03/07/2002 12:00 : 


http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branch

type=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mi

ndate=03%2F06%2F02+08%3A00&maxdate=03%2F07%2F02+12%3A00&cvsroot=%2Fcvsroot

looks like XBL Forms: 

bug 128947 comments: --------------------------------------


- Implement the :checked CSS pseudoclass which maps to the "selected" property
on option 

elements.  

Eliminate the _moz-option-selected attribute; move the actual selected state
into the option 

content node.

- Change all users of _moz-option-selected to use :checked

-- Add a third parameter to nsIDocument[Observer]::ContentStatesChanged to
indicate which 

pseudoclass changed, this is used for optimizing handling of :checked state changes.

Comment 12

[[not reading bugmail]]

ok, looking at checkins, This was actually bug 112699 bustage and this was fixed
with bug 129686. for 3-13 builds should work.

Comment 13

[[not reading bugmail]]

wfm, build 3-13-03 w2k, peter?  shall we resolve and close this out?

Comment 14

[Peter Trudelle]

sounds good, thanks!

Comment 15

[[not reading bugmail]]

verified, marking works for me.. see bug 129686 for a fix.

Comment 16

[Paul Wyskoczka]

v