3078 - Lynx hates bugzilla! (invalid HTML)

Status: VERIFIED WORKSFORME

(Bugzilla :: Bugzilla-General, defect, P3)

Description

[Hixie (not reading bugmail)]

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

Comment 1

[Terry Weissman]

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?

Comment 2

[Hixie (not reading bugmail)]

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

Comment 3

[Terry Weissman]

Reassigning to [e-mail], who now has front-line responsibility for
all Bonsai and Bugzilla bugs.

Comment 4

[Terry Weissman]

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.

Comment 5

[Hixie (not reading bugmail)]

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.

Comment 6

[Terry Weissman]

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.

Comment 7

[Hixie (not reading bugmail)]

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.

Comment 8

[Hixie (not reading bugmail)]

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

Comment 9

[Terry Weissman]

I just fixed that last example of bustage.

Comment 10

[Bryce Nesbitt]

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

Comment 11

[Hixie (not reading bugmail)]

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.

Comment 12

[Hixie (not reading bugmail)]

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

Comment 13

[Sam Allen]

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

Comment 14

[Bryce Nesbitt]

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.

Comment 15

[Bryce Nesbitt]

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

Comment 16

[Hixie (not reading bugmail)]

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 [e-mail] since you helped with this bug last time]

Comment 17

[Bryce Nesbitt]

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

Comment 18

[Hixie (not reading bugmail)]

Attachment: Screenshot of Lynx as I hit the "commit" button on this bug.

Comment 19

[Ben Bucksch (:BenB)]

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

Comment 20

[Terry Weissman]

[e-mail] 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 .)

Comment 21

[timeless]

Update? Tara, any thoughts?

Comment 22

[Matthew T (active 1999-2002)]

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.

Comment 23

[WD]

V.

Comment 24

[Dave Miller [:justdave]]

verified per previous comment

Comment 25

[Dave Miller [:justdave]]

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