Because the output of the "show_bug.cgi" script is invalid HTML, Lynx is having quite serious difficulty rendering the pages. In particular, the "additional comments" TEXTAREA does not appear, and the form is not submittable. The errors in question are: * unquoted attribute values (uris and % attributes MUST be quoted) * two "HEAD" sections and two "TITLE" elements per page * unknown "NAME" attribute on FORM element <<< main problem I think * missing DOCTYPE

Could you please give me a pointer to where to download the latest and greatest Lynx, so I can test any fix I might make?

Yup, sure. You can get Win32 and DOS binaries at: http://www.fdisk.com/doslynx/lynxport.htm The Lynx home page is: http://lynx.browser.org/ The source distribution page is: http://www.slcc.edu/lynx/release/ Other OSes have binaries available at: http://www.crl.com/%7Esubir/lynx/binaries.html

Reassigning to dmose@mozilla.org, who now has front-line responsibility for all Bonsai and Bugzilla bugs.

Reassigning back to me. That stuff about me no longer being the front-line person responsible for Bugzilla and Bonsai turned out to be short-lived. Please pardon our confusion, and I'm very sorry about the spam.

Actually, the problems are more widespread than just "show_bug". Almost the entire bugzilla interface is difficult/impossible to use in Lynx. Passing some bugzilla pages (eg, this one) through the w3c validator at http://validator.w3.org/ ...highlights the HTML errors. Other issues could be addressed by switching to HTML4 strict and doing trivial issues (eg, colours, fonts) with CSS. Terry -- I would be more than willing to cooperate in the creation of 'better' output from the bugzilla scripts. The only prerequisite would be that somehow the scripts be made more modular. At the moment, the HTML they create is very hard coded, so that any changes to the output require changes all over the scripts themselves. For examples, see: http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/query.cgi http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/bug_form.pl http://lxr.mozilla.org/mozilla/source/webtools/bugzilla/enter_bug.cgi In all three cases, the I/O and the logic are tightly intergrated. If they were separated, so that, for example, the system followed a principle more akin to the following: +----+ +------------+ | DB | | Form Input | +--+-+ +-+----------+ | | +-------+ +---------+---> | Logic | +--+----+ | +----+-------+ | Conversion | +----+-------+ +-----------+ | | Templates +------+ +-----------+ | | +--------+ +----> | Output | +--------+ ...then I would be happy to write the template files. The design principle outlined above would make the entire system much more readily extendible. For example, it would make switching to an XML based output a matter of merely putting in new templates, rather than carefully editing many different scripts. Design Notes ------------ A. If the system described above is created, then the template files would require both the main content of the pages and their associated headers. B. The system would need routines to: 1. Get all the data for the page into a generic format (logic). 2. Get all the generic format stuff into the output format (eg, escaping special characters such as "<", ">", and line feeds; converting uris and bug numbers in comment fields into links, and so on). This would have to be a shared library. 3. Merge the escaped data from step 2 into template files. C. The template files would need "repeatable sections" for, eg, tables, as well as optional sections. For example, the query.cgi script creates a table whose columns are decided dynamically. Hence the template file needs to delimit a template record, each individual field, and where in each field the data should be stuffed.

Bugzilla is too small a system to warrent all that generality. If I find myself needing to rewrite everything (because I need to generate XML or something), I might do something like you describe. But too many layers of indirection just lead to bugginess, inefficiency, and confusing code.

Fair enough. In that case, I would be willing to write some template files that are readable in Lynx, and that you would then have to re-incorporate into the bugzilla codebase. E-mail me if you wish to take me up on this offer.

Another example of invalid HTML occurs with the query error page. The markup contains two "TITLE" elements, one with a "Bugzilla bug xxxx" title and one with a "Bug Splat Error" title. (Also note the legacy...) See, for example: http://bugzilla.mozilla.org/show_bug.cgi?id=9999

I just fixed that last example of bustage.

I think the big problem is just invalid html. To check, go to: http://validator.w3.org/ And code the password in the URL: Bugzilla_login=mumble%40nextbus.com& Bugzilla_password=mumble& product=Webtools& GoAheadAndLogIn=Login

I have tried to design a version of show_bug's output which is compatible with Lynx. As far as possible I tried to keep the layout the same as it is now in IE4 and NN4. You can see this page at: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/bugzilla/show_bug.html The page was based upon both the output of the show_bug.cgi script, and the script's source code itself. That is why there are bits of text saying things like "$bug{'bug_status'}" all over the page. This should ease the reintegration of this sample page with the scripts' logic. The following files would need changing if this new layout was implemented: bug_form.pl -- changes to the "print" statements starting from line 205. CGI.pl -- changes to logic and output of navigation_header(), lines 194-215. CGI.pl -- changes to print statements in PutHeader(), lines 472-505. defparams.pl -- changes to headerhtml (line 137), bannerhtml (line 145), and blurbhtml (line 155). any scripts using navigation_header() -- addition of bug id parameter. (The change to navigation_header() is to allow it to have bug-specific links. See the sample page for more details.) If you wish to use the page to fix this bug, feel free. If you would like me to have a go at updating the scripts myself, then just ask (although I am quite new to perl). Note that this should not be too difficult, as it is generally only the contents of the "print" statements that need changing. I also wrote an alternative page that has the fields in a more logical order. You will find this page at: http://www.bath.ac.uk/%7Epy8ieh/internet/projects/bugzilla/show_bug2.html It is probably a bad idea to implement this, however, since moving the UI around too much will just confuse users.

Note. Another problem is that Lynx, like IE, doesn't support mime/multipart HTTP messages (sad, but true). (Emacs/W3 supports them a little.)

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

Changes that make BugZilla usable with Lynx are pending with Terry. The use of "server push", and invalid HTML were the keys. I don't promise it is *easy* to use with Lynx, just possible.

I'm submitting this with Lynx, as some proof it is at least better now. Remember, I promised functional, not beautiful.

Reopening. The TEXTAREA for entering Additional Comments no longer appears on Lynx when viewing this page, which makes it pretty much impossible to update bugs! The rest seems to work a lot better though. Thanks Bryce! [cc'ing bryce-mozilla@nextbus.COM since you helped with this bug last time]

I just added this comment using Lynx. What's the problem?

see "Bugzilla HTML Templates" Project <http://sourceforge.net/project/?group_id=1907>.

tara@tequilarista.org is the new owner of Bugzilla and Bonsai. (For details, see my posting in netscape.public.mozilla.webtools, news://news.mozilla.org/38F5D90D.F40E8C1A%40geocast.com .)

Update? Tara, any thoughts?

This comment and associated changes, made using Lynx v 2.11. It's not going to win any prizes for Lynx-compatibility, but it works. Worksforme.

V.

verified per previous comment

moving to Bugzilla product reassign to default owner/qa for INVALID/WONTFIX/WORKSFORME/DUPLICATE