Klein Duijmpje Reporter
	Description • 25 years ago

The text below was posted in the Communicator newsgroup. I believe we need a 
'Go' button on the Mozilla UI.....
There are no easy ways around the described problem in Netscape 4.x so the user 
is best off using IE 5.0 at the moment.
Mozilla should cater to the 'challenged'.....

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

Greetings,

I am writing for a friend who is a quadriplegic.  He is able to browse
the web using a motion sensitive baseball cap (to move the cursor) and a
straw (to simulate clicking the mouse) through the application "Joymouse
4.1."  The only real trouble he has is that if he is on a certain
webpage and wants to view a higher level (for example, let's say he is
at <my_site/pictures/my_dog> and he wants to view the higher level
<my_site/pictures> without the "my_dog" part,) he is able to move the
cursor (with the baseball cap) up to the website window, click the mouse
after the word "pictures" and then delete the words "/my_dog."  The next
step to view the higher level (i.e., the <my_site/pictures>) would be to
hit the Enter Key on the keyboard -- which, of course, he can't do
because he is a quad.  At this point he has to call someone into his
room to hit the Enter key for him.

Is there any way to add an Enter Key on the Netscape window so that he
can hit Enter himself?

Thanks for any help you can give.  Please direct all replies to
"StAlfnzo@cruzio.com"

	Gervase Markham [:gerv]
	Comment 1 • 25 years ago

OK. Here are some thoughts:

I've tried pasting a Return from the Clipboard, but Windows doesn't want to do 
that. I've tried using a text insertion program, but using a mouse with it loses 
focus from the browser, and using a hotkey defeats the object. I also tried 
Character Map, but I think that would hit the Clipboard problem.

There are probably other apps that don't behave well, and other quads with the 
same problems, so you could attack the root cause instead of this one symptom. 
You would do that by writing an app which was "always on top", and tapping it 
didn't change the focus, and which inserted user-defined sets of characters.

Would it be possible to implement a Go button just using Mozilla skins? Anyone?

Or, and I think this might be quite intuitive, we could enhance the Forward 
button, to do an "Enter" when the URL is edited. After all, it takes you 
Forward, right?

StAlfnzo@cruzio.com has been added to the CC: list.

Gerv

	Asa Dotzler [:asa]
	Comment 2 • 25 years ago

It would be possible to impliment a go button in XUL.  It was done last summer 
in one of the proof of concept packages put together by one of the n.p.m.ui 
regulars (maybe pete?).  I swear this bug is already reported but I can't find 
it. Confirming.  I suppose this should go to XPFE gang.

	Chris Waterson
	Comment 3 • 25 years ago

browser

	Asa Dotzler [:asa]
	Comment 4 • 25 years ago

adding helpwanted keyword (anyone that wants to submit a patch, feel free.  I
don't know if it will go anywhere but...) assigning to nobody@mozilla.org where
unwanted helpwanted bugs live.

	Jesse Ruderman
	Comment 5 • 25 years ago

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

	Jesse Ruderman
	Comment 6 • 25 years ago

Related to the anecdote is bug 33684, asking for an "up" button to chop off the 
last part of a URL automatically.  It was marked as WONTFIX.

	Gervase Markham [:gerv]
	Comment 7 • 25 years ago

Given that anyone can make a skin with such a button (and people have), and the 
design of the Mozilla UI is (merely by weight of numbers) done for the 
convenience of greatest number, this should be WONTFIX too. I don't think this 
is harsh - after all, Microsoft don't bundle "JoyMouse 4.1" with Windows...

Gerv

	Jesse Ruderman
	Comment 8 • 25 years ago

There should be code in mozilla that these skins can call, though.  It would 
suck if each skinmaker did it separately (and probably not too well).

	John Dobbins
	Comment 9 • 24 years ago

I'm not sure if "Won't Fix" is correct because Mozilla HAS a go button. The XUL 
allready includes the button. The Classic and the Modern skins just don't 
display it. Look at navigator.css in the \navigator\skin directory. The 5th item 
from the bottom is
#go-button  
  {
    display               : none;
  }
All you have to do is edit this line and the go button will appear next to the 
search button. 
This bug could easily be resolved as fixed by making patched versions of 
navigator.css available for download for persons who need a go button.

	John Dobbins
	Comment 10 • 24 years ago

This bug should be reopened. Mozilla should be fully accessible for the
challenged. My last comment touches on how easy it is to display the go button
that is allready in XUL. I realize that most users don't want the extra button,
so what I'm proposing is that Mozilla.org add an accessibility page where people
who are challenged can download patches that would add the features they need.
The go button would would help quadriplegics, and the blind. The software for
the blind also requires this feature. Other features for the page could include
skins with high contrast and large fonts for people with limited sight. This
would not affect the versions of Netscape/Mozilla most people use.
If no one has the time for this, then assign it to me. I will modify the files
and write an accessibility page.

	Klein Duijmpje Reporter
	Comment 11 • 24 years ago

For those who haven't yet.... have a look at Aphrodite 0.04
Aphrodite has a 'Go' button and not only that with 'View' --> 'Toolbars' it is 
possible to hide this button if so desired.
Seems a relatively simple implementation and hence this 'bug' would be fixed.

	John Dobbins
	Comment 14 • 24 years ago

Added Atachments. These are the modified navigator.css files for Modern and 
Classic skins. Also I filed bug 45963 (Accessibility for the Challenged) Today 
regarding the Lack of Accessibility in Mozilla. 

	Asa Dotzler [:asa]
	Comment 15 • 24 years ago

re-opening.  adding patch keyword sending to UI Design Feedback default contacts.

	Asa Dotzler [:asa]
	Comment 16 • 24 years ago

reassign

	Matthew T (active 1999-2002)
	Comment 17 • 24 years ago

No, having to install a completely separate navigator.css just to turn a button 
on and off is bogus. The Go button should be much easier to toggle than that. 
And some users of a given Mozilla installation may want the Go button, and some 
may not; so it should be dependent on stuff in the user profile, not stuff in 
the binary directory.

There should be:
* a `/ Go button' item in the context menu for the location toolbar (not the
  context menu for the location bar, but for the toolbar itself)
* a `Go button in location toolbar' checkbox in the Navigator category of
  prefs (or whatever toolbar customization dialog eventually supersedes it).

Removing patch keyword, adding softui. Marking dependent on bug 24413, since 
allowing independence from the keyboard would appear to be a requirement for 
WAI section 2.1.

	Matthew T (active 1999-2002)
	Comment 18 • 24 years ago

[Feh ... I didn't mean `dependent on bug 24413', I meant `as a blocker for bug 
24413'.]

	John Dobbins
	Comment 19 • 24 years ago

Bug 15144 addresses the ability to add and remove toolbar buttons. The go button 
is mentioned in a comment on that bug.

	Asa Dotzler [:asa]
	Comment 20 • 24 years ago

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

	Asa Dotzler [:asa]
	Comment 21 • 24 years ago

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

	Matthew T (active 1999-2002)
	Comment 22 • 24 years ago

Resummarizing. We already have a `Go' button, we just need a way to toggle it 
which is easier than hacking user.css.

	John Dobbins
	Comment 25 • 24 years ago

The two test cases are modified files. navigatorOverlay.xul adds a new item to 
the view menu, Navbar Buttons, and a sub-menu to toggle the go button. I also 
added the ability to toggle the search button and the new print button. 
navigator.xul places the three buttons in boxes.
Clicking on the three items in the Navbar Buttons sub-menu toggles the selected 
buttons on and off.
This has been tested on Win98 with the Modern, Classic, and my Neoclassic (see 
bug 8415) skins.
It needs testing on Linux and the Mac.
navigatorOverlay.xul is for TESTING only. It isn't i18n ready.

	Rann Bar-On
	Comment 26 • 24 years ago

a couple of comments:

-  From Dino! experience, patches to navigator.xul, navigatorOverlay.xul,
navigator.js and navigator.dtd are needed to enable a user to turn buttons (any
buttons, or other elements for that matter) on and off.  (See dino! for
reference).  In other words, the user either has to hack XUL/JS files or get a
patch (usually as an XPI, as dino! has it).  Overlays need to be imported into
these files and are therefore no real use either.

-  Since XUL does not currently support context-based patches (see <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=49390">49390</a>), this would
involve overwriting the files mentioned above.  Obvious problems arise.

-  As a third problem, any menu-based options to hide/show buttons must either
use the persist="checked" property of checkboxes, which is very buggy ((see <a
href="http://bugzilla.mozilla.org/show_bug.cgi?id=15232">15232</a>), or write an
option to prefs.js and read it at startup, which is ridiculously cumbersome (I
can provide code to show this if needed).

Solutions:
- fix 15232 and use a dino!-like model to enable/disable elements of the UI.
- fix 49390 and make text-based xpi patches availible to users.

A final comment: It's all very nice that Mozilla's UI is XUL based.  This,
however, does not immeadiately imply that it is easily customisable.  The case
of the go button, and how much fuss is being raised about various UI elements,
shows this clearly.  People in general are not willing to hack XUL/JS files.
This shows once again that we need to provide customisation tools for both
companies who want to modify the UI for their employees and individuals who,
either because of personal taste, or (far more importantly), a physical
disability, require extra buttons or other such relatively straightforward (for
coders) modifications.  Not providing such tools is a very big mistake and this
should be carefully considered.

	Rann Bar-On
	Comment 27 • 24 years ago

apologies for the html tags in the previous comment, I didn't know how bugzilla
handles references.

	John Dobbins
	Comment 28 • 24 years ago

bug 49390 and bug 15232 are good long term soluations. However my changes are so
minor that they could easily be in for M18, and would resolve this bug, along
with bug 44455 and bug 49201.

	Matthew T (active 1999-2002)
	Comment 29 • 24 years ago

Hyatt was talking in #mozilla about implementing a basic UI for turning toolbar 
buttons on/off. CCing him.

I hope that the use of a submenu in the View menu is just for testing purposes. 
In the real world, people just aren't going to toggle buttons on/off often enough 
for it to deserve a menu item, and it should have a dialog instead as I described 
previously.

	John Dobbins
	Comment 30 • 24 years ago

The Files are test cases to see if turning off buttons have any unexpected side 
effects in the skins currentally in Mozilla, or in some of the more popular 
skins avaible for download.
I added the printer and search buttons to the go because there are 2 seprate 
bugs about these buttons, and all 3 buttons should be dealt at the same time so 
they UI is constant. Comments were attached to the bugs.
The Navbar buttons submenu is a quick hack to test this feature.
Though if the hack found it's way in, the buttons submenu would more use than 
the option to turn off the whole navbar that is in the current menu. Few people 
will ever want to toggle the whole bar off.
Mozilla should ship with all buttons enabled. (So people know they are there)
Then most people will use this feature 1 time, to kill the buttons they don't 
want. The UI for this belongs in prefs in the Navigator section.

	Rann Bar-On
	Comment 31 • 24 years ago

Hyatt was talking about implementing a UI to turn buttons on and off??!!?  This
idea was floated (and is being implemented) by the Dino team, and has been
around for weeks.  Nice of you to listen when a developer proposes it, but not
when a mere user does something about it.  A prefs panel for turning _any_ UI
button on and off should be out by the end of the week on the Dino site.  We
would have no problem putting the code for the prefs panel on here if so
requested.  However, it is rather insulting that our ideas have been ignored in
favour of identical ones, simply because we are slightly lower down on the
development ladder.  If you would have listened to suggestions and ideas from
us, your users and testers, and perhaps even lent us some support, this problem
would have been solved a long time ago, and a lot of users would have been much
happier.  That bold statement isn't groundless, either:  the number of people
using Dino, and offering help and suggestions, has been rocketing in the last
couple of weeks.

Just in case you want to see what us mere users have been doing:
http://sites.netscape.net/dinoproject/

And on a more conciliatory note: the above comments are not aimed at any
developer in particular, but rather at the attitude of many developers.  I dare
say I am expressing the frustration of many other users, who have been
requesting minor features that would simply make our lives easier, and that we
think would help others too.  Most (probably almost all) of these suggestions
have been dismissed.  Mozilla, like any consumer product, should be answerable
to its users.  Currently, I don't see that.

	David Hyatt Assignee
	Comment 32 • 24 years ago

What's Dino?

	Rann Bar-On
	Comment 33 • 24 years ago

Dino is a project aimed at fulfilling user requests (especially UI) that mozilla
developers future or ignore.  Check out the page, linked to above.

	David Hyatt Assignee
	Comment 34 • 24 years ago

Hmmm.  I'm not sure why you're so upset, Rann.  I think your problem is one of 
advertising.  

I'd never even heard of Dino until I was cc'ed on this bug report.  I see now 
that something has popped up on MozillaZine just today, which is good, since 
most developers read that, but I think you're assuming that you're being ignored 
when many developers simply haven't heard about your efforts.

FWIW, I went and talked to my other team members, and none of them had heard of 
Dino either.  Well, now we have.  

Anyway, I have the UI fully implemented for turning key buttons on and off in 
prefs (since I was working on it before I even knew you were doing it).

Accepting this bug, since I have the fix in hand.

	David Hyatt Assignee
	Comment 35 • 24 years ago

To address Matthew Thomas' earlier concerns, I do not use the View menu.  I just 
added a group of checkboxes (in a scrolling list) in the Navigator prefs panel.

I agree that having all of those toggle options on the View menu would be 
cumbersome.  I think this belongs in prefs (and perhaps in intelligent context 
menus on the toolbars themselves).

	John Dobbins
	Comment 36 • 24 years ago

David, This bug was originally a RFE for a go button. If you aren't actually 
adding the Go button to the Classic and Modern skins then after your check-in 
could you update the summary and pass this to Ben, instead of marking fixed?
Or should I file a new bug after your check-in?

	Rann Bar-On
	Comment 37 • 24 years ago

David, first of all, I apologise for the over-aggressive tone of my last post.
However, my main point remains valid: if you (and others) had simply popped on
to #mozillazine, or carefully read posts on www.mozillazine.org, you would have
been aware of Dino, and of other user concerns, weeks ago.  All this goes to
show is that, in my opinon, and in that of many others, most of Mozilla's
developers and some QA's have lost touch with user opinion and requests.  It's
one thing to get a standards-compliant browser developed, and an entirely
different thing to get a standards-compliant browser that users like, and are
therefore likely to accept as their first-choice browser.  I have heard various
people saying that Mozilla isn't aimed at users, but rather at developers.  I
couldn't disagree more.  Mozilla's aim was, and remains, to develop a fast,
standards-compliant browser that will be accepted by as large a proportion of
internet users as possible.  By losing touch with your users, you (not
personally, but rather as a part of the dev team) are reducing the chances of
mozilla being accepted.  I am very much aware that my charges and accusations
are harsh, but I very strongly believe in the need for developers of any
software (and for that matter, anything), to stay in touch with their userbase.
 Right now, I just don't see that coming from the Mozilla development team.
Mozilla is a fabulous browser, and has an absolutely huge potential.  I appeal
to you, and all developers, to help Mozilla realise that potential by simply
paying a little more attention to the various forums that your testers and users
use to express their concerns.  Thanks.

BTW, I'd be glad to discuss this on IRC (my nick is Termite, and I'm on
irc.mozilla.org most afternoons US time), or by direct email
(termite@global.bw).  Once again, thanks for taking the time to read and respond.

	David Hyatt Assignee
	Comment 38 • 24 years ago

John, there has been a Go button in the XUL for months. :)  It's just been 
hidden.

	Joseph Elwell
	Comment 39 • 24 years ago

These types of bugs are what I believe causes people to think Mozilla is
bloated. Do we really need more UI for turning on and off UI? Isn't the code
open source? Can't we just let people that want to deviate from the Mozilla
distribution hack the xul themselves? or define their UI prefs in that user.css
file?

	Jesse Ruderman
	Comment 40 • 24 years ago

The ability to toggle these buttons doesn't need to add to "pref bloat".  It 
could be in the context menus for the toolbar itself.  And remember, not 
everyone likes editing configuration text files.

	David Hyatt Assignee
	Comment 41 • 24 years ago

I totally disagree.  Toolbar customization is a much-needed feature, and you 
shouldn't have to use a different set of XUL (or hack on existing XUL) just to 
achieve this customization.

	David Hyatt Assignee
	Comment 42 • 24 years ago

Errr, that was to jelwell, not to jesse. ;) 

	John Dobbins
	Comment 43 • 24 years ago

David, I'm aware of the Go button in navigator.xul and the line, display : none, 
in navigator.css. See my July 11th comment above.
If your checkin dosen't include patches to navigator.css for the modern and 
classic skins then it will remain hidden, and someone will file a bug report 
tomorrow that it dosent work for the go button. The attachments I made a month 
ago (go-classic and go-modern) are out of date versions of navigator.css and 
have the changes that un-hide the go button. go-classic only displays the 
button. It dosen't have an icon or hover and hover-active states like the other 
classic buttons. I assume Ben will want a Go button that matches the other 
buttons in Classic, so I suggested you pass this to him. If you want an example 
of a three state go button that will work in classic see my Neoclassic skin at 
http://x.themes.org , for mods to navigator.css though my icons would look out 
of place in Classic.

	Antony Mawer
	Comment 44 • 24 years ago

"if you (and others) had simply popped on to #mozillazine, or carefully read 
posts on www.mozillazine.org, you would have been aware of Dino, and of other 
user concerns, weeks ago."

FWIW I'm a regular reader of MozillaZine and up until the recent article there, 
I hadn't heard a thing about 'Dino' anywhere on the site. Additionally, as far 
as I'm aware, #mozillazine is more a 'users' channel for Mozilla's end-users and 
enthusiasts to sit around and chat. #mozilla is where the serious developer talk 
goes on, and where most of the developers are found.... (correct me if I'm wrong 
here! :)

	David Hyatt Assignee
	Comment 45 • 24 years ago

Fixed.

	Decklin Foster
	Comment 46 • 24 years ago

verifying, linux cvs 082309