Closed Bug 6211 Opened 25 years ago Closed 20 years ago

View Page Errors (Web Development Console)

Categories

(SeaMonkey :: General, enhancement, P3)

enhancement

Tracking

(Not tracked)

RESOLVED WORKSFORME
Future

People

(Reporter: ian, Unassigned)

References

()

Details

(Whiteboard: [Hixie-P0][Hixie-2.0])

An option to view all errors found with the displayed document would be
very useful for developers (especially since many do not bother to use
validators, assuming that if it looks ok in their browser then it must
obviously be correct).

Such an option should report errors in the XML, HTML and CSS related to the
document, as well as any problems discovered when trying to download
related resources (eg, any HTTP errors like 402s when downloading images
or 404s when downloading stylesheets).

[ccing original contributors to the idea on mozilla-layout]
as long as we're talking rfe, it would be nice if an error was reflected in the
status bar so that you could click on some "markup error" icon to show the
errors.  Maybe a little gecko-shaped icon that changes colors, or breaks when it
finds an error.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → REMIND
[ccing peterl]

Peter, is the CSS parser able to report errors? It would be useful if it could
contribute a report of its own to the "Document Errors" window.

Something else that must be mentioned on the Document Errors window is if there
are any missing glyphs (see also bug 6585). Some suggestions as to where some
suitable fonts could be aquired would not be a bad idea either.

In conclusion, we are going to be needing all the parsers (HTML, XML, CSS,
JavaScript, et al), the network library (broken images, missing stylesheets),
the rendering system (missing glyphs), the script engines (JavaScript again)
and the image library (corrupt JPEGs, GIFs, PNGs...) to have some sort of common
API to report errors with.

Then reports from all these components are going to have to be collated together
and made available to the user.

Looks like when the time comes, this bug is going to have to spawn a litter of
mini bugs...
Status: RESOLVED → VERIFIED
*** Bug 8575 has been marked as a duplicate of this bug. ***
A few things:

A suggestion for the status icon would be a document containing a tick or cross.
There should be a distinction between errors (eg bad images) and warnings (eg
use of deprecated html features).
I think there should be a warning on all pages not using HTML 4 to say that it
is an old version of HTML and should be updated.
I think giving navigator  the ability to authorize HTML is a great idea, especially if while editing your own pages if there is an html error (such as the infamous, no close table tag and the entire table or even page does not appear) that a small symbol could appear in the status bar and when clicked would bring up a window showing the problem (such as a small version of the html icon with a small x in it?) , then perhaps you could even have the option of e-mailing the webmaster to tell him/her of the error and how to fix it! Of course in the case of pages  hosted by a company it would likley need to search that sites html files for a mailto link for the sites webaster.

The mail sent could be customizable. Just image if this worked and enough people using navigator 5 would use this feature and if the webmasters would fix the problems on their pages.

Anotger possible addtion to this. Many people place all their images in sub directories, well just say in the code you speel the sub-dir in on of the src tags wrong, how about if it could also dectect this and tell you that this is the likley reason the image is not showing up and even what to change it too (heck if you're editing a page on your HD it could even make the change for you, but do via a search and replace type command (ie opens your (or switched to it if it's open) default ascii text editor and uses cut and paste commands to replace the bad dir name with a good one then saves it). Wouldent that be sweet, not only having it tell you of html errors, but giving you the option of having it fix them! Is this possible?
Automatically e-mailing the author would be good, but I think it'd be a little
hard to extract an e-mail address, since the user really needs to look at the
page to determine whether it's the correct address (there wouldn't be a unique
address that is actually the author's address enough to warrant the effort).
Does HTML have an author-email meta tag that you might use?  If so, this would
be worth it!

The correct-on-the-fly behaviour is, I believe, kind of what the parsers do
already.  I think it'd probably be a lot harder for path discovery although it
could work.  However, I'm not really sure we want to encourage bad pages to
display properly - it would only encourage bad HTML to survive, which other
browsers couldn't display and webbots could choke on.  That's a mistake from the
past that should not be repeated.  The only reason this should be done is for
backward compatibility (and as far as I know, no browser has ever done this path
replacement).

Also, this makes me think that if an error/warning is discovered, an explanation
of what the browser did would be good, eg

Warning: Use of deprecated tag <FONT> ...
Action: Displayed anyway.

Error: No end tag for < ...
Action: Inserted end tag at ...

Error: 404 Not Found at "http://me.com/a.png"
Action: Displayed broken image.
Automatically mailing the author would be a very bad thing, especially if
Mozilla is as popular as we hope it will be. I do not think webmasters would
appreciate getting mail bombed because 600,000 people visit their sites with
a new browser and they happen to have a misspelt attribute somewhere.

However, the author's e-mail address, or a page containing contact information,
should indeed be made available. That is covered by bug #2800, since the
information is normally given using a LINK element:
   <LINK rev="made" href="py8ieh=bugzilla@bath.ac.uk">

I like the idea of saying what action was taken as well as what the problems
were, by the way.
I wouldn't want Moz to do it "automatically" in the sense of doing it without
the user's consent, but certainly to bring up a prepared message saying exactly
what is wrong and how the page author could fix it would be useful.  Maybe if
web authors were getting all of these messages they might be more careful about
the pages they design.  Certainly we would need to look at what constitutes an
error you would report to the page author.  For example, we wouldn't want people
complaining to web page authors about the server being overloaded which led to
a broken image.

Another thing I think we should check is the web accessibility guidelines.  I
don't know offhand if there's anything that's checkable and not covered by other
standards (eg I think ALT text is compulsory in HTML 4 <IMG>s?), but if there is
anything, it should be checked.

Also, I think the status bar should distinguish between warnings but no errors
(say display an exclamation mark) and errors and possibly warnings (say display
a cross).  Of course exactly what constitutes a warning or an error is up for
debate.  Maybe we should distinguish between bad pages and network errors (that
is if network errors really belong here).
You could also have informational messages in this tool, such as "redirected by
site from x to y".  You would want the status bar to display the presence of
such messages, and this would be yet another little icon (a friendly one this
time).  If this were included, perhaps "Page Log" would be a better name.
I've had another thought about how this could work.

Javascript errors tend to cause annoying multiple popups.  Now having ten
million of these in a row is really annoying, but if only the error log
appeared, with all the errors aggregated into one window popped up, it would be
much better.

But why restrict yourself to Javascript?  Any class of error should be able to
automatically pop up the log.  But you wouldn't always want everything to pop
up.  What would determine this?

Well, there are a couple of vectors you can look at this from - the subsystem
(JS, Java, Network, HTML, CSS, etc) or the severity (warning, error, etc).

Either way, having a user set preferences would be very good.  But if the
default preferences had this on all errors, then it might encourage web pages
authors to clean up their act.
More thoughts:

This should ideally be separated into two types of problems - page loading
(netlib stuff) and page browsing (xml, html, css, js, images).  The logic is
that each sort of problem lies with a different person.  Loading problems are
the fault of the web client, server or the routers in between.  Browsing
problems can also be, and usually are, the fault of the page author.  Any email
reply could only be initiated on the second sort of problem.

You would have two little status icons on the status bar.  Each would be as
following.

Blank (No Icon) - No messages.
Informational (i symbol) - Messages, all informational.
Warnings (Exclamation Mark) - Messages, includes warnings, but no errors.
Error (Broken Page) - Messages, includes errors.

Please don't shoot me if these icons aren't internationally recognised.  =)


Here's some examples of messages:

Informational Loading

Site offered a cookie (blah blah ...).  Accepted.
Site permanently redirected from "http://a.com/" to "http://b.com/".  Bookmarks
updated.
Site temporarily redirected from "http://a.com/" to "http://b.com/".
The web server serving this page uses a superceded version of HTTP, Version 1.0.

Warning Loading

No idea what might go here.

Error Loading

URL "http://a.com/a.gif" not found (Error 404).  Displayed alternate text "My
Picture" instead.

Informational Browsing

This page uses a superceded version of HTML, Version 3.0.

Warning Browsing

Use of deprecated tag <FONT>.  Applied anyway.
Use of deprecated tag <FONT>.  Overridden by CSS property.

Error Browsing

Javascript/HTML/XML/CSS errors ...


Obviously with some of these, informational messages would be the norm.

Much of this information is just not available to interested parties at the
moment.  It would make diagnosing problems much easier and make the web a much
better place.
I split off the auto-email issue as bug #13011.
Another thing that should happen is that on errors, a reference to the relevant
standard should be given, where applicable.

This, and the rest of the issues should help prevent the attitude that NN or Moz
is a browser that doesn't display pages that work in IE so it must be broken, as
well as making it obvious how badly IE does some things.
As well as preventing spurious bug reporting.
Some of this is good.
Some of it is insane!
The web server serving this page uses a superceded version of HTTP, Version 1.0.

No!!! HTTP is backwards compatible! Beides, if they want to know what version of
HTTP, they can use the informational thing to check the headers
Summary: View Markup Errors wanted → View Page Errors wanted
Refined description a bit to reflect the more general possibilities of this
report.
I really hope this makes into into the initial release - it would be very useful
to allow reporting that a "NavQuirk" was found, which would help iron out
potential confusion among web developers.
QA Contact: leger → rickg
Updating QA Contact.
A few implementation notes: The messages need to be both friendly for the
casual user *and* contain enough useful information for developers to figure
out the problem and correct it.  IE leans totally to the former end of the
spectrum, giving us very vague and generic errors that could be caused by any
number of transient or serious problems.

At the same time, 'One or more errors occurred in this web page that may
prevent it from displaying correctly,' is all some of the more casual web users
need to see, and I highly recommend such generic text at least in addition to a
list of detailed error messages (which alone might be meaningless to many).

We should also be careful that netlib-ish problems that could be potentially
caused by transient issues (such as 'Net congestion or connectivity problems)
are noted as such.  Users like to assign blame and it'd be nice if this
mechanism didn't inadvertantly make it seem like the author was at fault for
*everything* reported.

All in all, quite an excellent idea, and if adopted, I encourage the sources of
such messages to follow relatively consistent and rigid guidelines as to how
messages are formatted and phrased.
A suggestion for status bar text:
------
Done -- 1.16 s (warning: document contains errors)
------
Simple, unobtrusive, but at the same time not the sort of thing a 
self-respecting Web designer wants to see under their pages.

Beyond this, I don't think it's Mozilla's job to be a detailed validator, as 
well as a browser. There are plenty of perfectly good validators on the Web 
already. And the Mozilla validator will become useless as pages begin to be 
written in HTML 5.0 or 6.0 (unless you download, cache, and use the DTD from the 
address given in the !DOCTYPE ...).

Finally: Do NOT, on any account, complain about a page using an out-of-date 
standard -- whether HTML, HTTP, or whatever. There are good curatorial reasons 
why some pages should be kept in their original form (including some on 
www.w3.org!).
nominating for beta based on newsgroup comments. A simple message could focus 
the blame on the web-page author instead of mozilla which will otherwise be 
assumed to be wrong.
Keywords: beta1
Reopening bug for consideration. We want to make the best impression we can and 
leaving this REMIND until after we ship doesn't sound like a good idea.

"Viewer App" doesn't sound like the right component. Maybe "Layout" or 
"Browser"
Status: VERIFIED → REOPENED
Resolution: REMIND → ---
PDT-
Whiteboard: [PDT-]
I don't think there's any reason for Moz not to validate, I suspect it already
does most if not all of the required tests anyway.  Any unknown doctypes should
not be attempted to be validated.

As long as messages about previous versions of HTML and HTTP are informational
rather than warnings and words like "superseded" rather than "obsolete" are
used, I don't see a problem with old version messages.
Folks -- 

This is marked remind because it's not an official feature that we're expected 
to ship. I've done my best to enable this, and once a few more event bugs are 
fixed, I can turn on the first (simple) version of page errors. Don't worry, 
"remind" doesn't mean Ignore.
Status: REOPENED → RESOLVED
Closed: 25 years ago25 years ago
Resolution: --- → REMIND
*** part of bug #28558 was stated as a dupe of this one.
I like this idea of reporting helpful hints to authors, even if it is
just a "document contains errors" on the status bar, for this could then
provide an incentive to authors to check the document under consideration in
a more elaborate validator.

In MathML, we know when we encounter erroneous markups. For example, a <msup>
expects a base and a superscript, and we know when something is missing. If 
there was an architecture in place for reporting errors, say through a function: 
error(componentID, errorID), we could also call the function to dispatch error
messages via the error handler. However, we don't know on which line the 
error happens :-)  At best, the error handler could do The Right Thing(TM)
with componentID/errorID using an external I18N/L10N-friendly file, and there
could be an onError js-function that webmasters could hook in their pages for
custom notification. Otherwise, the error handler could simply say 
"document contains errors" on the status bar.
*** Bug 29404 has been marked as a duplicate of this bug. ***
How about one icon for correctness under each version of HTML, and another icon 
for HTML that does not conform to any particular version of HTML (maybe it uses 
some tags from HTML 4 but also uses a tag marked as superceded in HTML 4)? I 
was thinking a version number in black with a green check mark next to it for 
correct, and a red X for incorrect.

The same space could be used for other icons to indicate that a png image is 
being displayed (not as part of a page), etc.
Seems to me that it makes more sense just to indicate whether or not it conforms 
to the version of HTML specified in the DOCTYPE and provide an option to open up 
a list of errors. No DOCTYPE at all could be considered an error as well, I 
suppose, in order to discourage the use of unlabelled tag soup.
> No DOCTYPE at all could be considered an error as well, I suppose, in order 
> to discourage the use of unlabelled tag soup.

Which versions of HTML require (as opposed to suggest) the use of doctypes?

As mpt@mailandnews.com said, we should not complain about the use of superceded 
standards.  If a page complies with any version of a standard (with or without 
a doctype), no error should be issued.  If a page without a doctype does not 
comply with any specific version of the standard, then it's ok to add a warning 
at the end that mentions the absence of a doctype.
Would it be useful to keep a list of IE/NS4x "parity bugs" that, although they 
should be "fixed" in mozilla to match the behavior of other browsers, should 
also be covered in the error list?  I nominate bug 31482 for this list.
It'd probably be better to just not check pages without a DOCTYPE at all. Of 
course, that would eliminate much of the purpose of the feature--maybe the 
feature wasn't such a good idea to begin with. All the problems seem to have 
less-than-satisfactory solutions.

[withdrawing my vote for this bug/feature request]
I've been reading reviews of the iCab browser, which has a smiling or frowning 
face depending on whether the current page is valid HTML. Two things came through 
repeatedly from the reviews: (1) the reviewers really liked the feature, and (2) 
iCab hardly ever smiles. There aren't many pages out there that validate.

So, given that I'd get sick of seeing `(warning: document contains errors)' all 
the time, I think we should go for a minimal display like iCab does. A little 
page icon at the left end of the status bar, overlaid with either a green tick, 
an orange exclamation mark, or a red cross -- for valid pages, pages with 
warnings (such as timed-out images), and errors (such as HTML errors, or missing 
images) respectively.

A dialog dedicated to displaying errors in various categories can wait until 
later.
Minimal display is cool, but you should be able to double-click it to see the 
errors.  Otherwise, how will the feature be debugged?
A message of mccabe curled from n.p.m.xpcom. people on this bug
list might find the message relevant.

     Subject: nsConsoleService now in XPCOM
        Date: Wed, 19 Apr 2000 16:39:48 -0700
        From: Mike McCabe <mccabe@netscape.com>
Organization:Encom
  Newsgroups: netscape.public.mozilla.xpcom




I recently added nsConsoleService to XPCOM.  The console service supports
logging of messages that are intended to be recorded or displayed to the
user.


The JavaScript Console

One client of the console service is the JavaScript Console.
(tasks->tools->JavaScript Console) The JavaScript Console polls the console
service for messages that have been logged so far, and registers itself with
the service as a listener for new messages.  The console service itself
doesn't depend on JavaScript.  Everything in the console service is
scriptable, and the JavaScript console is implemented in pure XUL/js.  It's
very bare right now, but I've been working with Syd to cook up a beautiful
UI for it.


Logging Errors

The console service should be used to log any error that might be of concern
to a user or UI/component developer.  The console service currently gets
messages from XUL and content JavaScript, XPI JavaScript, and JS
Components.  Other candidates are Prefs, the XML parser and XPConnect.  I
intend for the error list to be filterable from the JavaScript UI, so be
promiscuous with what you log.

To log a message, call LogStringMessage on the service.  If you want to
associate more information than just a string with your message, make an
XPCOM object that's QIable to nsIConsoleMessage and call LogMessage -
JavaScript errors currently log instances of nsIScriptError.  Console
listeners can then attempt to QI from nsIConsoleMessage to richer message
types that they know about.  An example of logging a message is the
JavaScript Component loader, 

http://lxr.mozilla.org/seamonkey/source/js/src/xpconnect/loader/mozJSComponentLo
ader.cpp#197


Threadsafety

The console service is intended to be threadsafe; you should be able to log
messages to the service from any thread.  Listeners registered with the
service are proxied when they are registered.  When a new message is logged,
each listener will be notified (asynchronously) on the thread from which it
was originally registered.  (For this reason, each listener must be
registered on a thread with an event queue.)


Please let me know if you have any suggestions -

Mike
So, mccabe, does this distinguish info, warnings and errors?
Matthew -

The nsIConsoleService backend does provide information to distinguish warnings
from errors.  The nsIScriptError interface 'flags' field copies the
error/warning information from the JS Error structure.

Marking this bug as a dup of the js console bug.
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
Marking as dup of js console bug.

*** This bug has been marked as a duplicate of 4263 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Target Milestone: --- → Future
Reopening. If I read mccabe's comment correctly the JS console logs XUL JS 
errors, but this bug is about marking HTML, XML, CSS, etc markup errors in a 
page.

Now maybe that /could/ be pumped into the console, but until it's going 
somewhere this bug should stay open.

Setting milestone to "Future" because it is an enhancement
We used to have a little icon in the lower right that specified whether the 
parser thought the content model was well formed. This and other features are 
being pushed out though. Marking remind.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → REMIND
I thought we were leaving bugs open against a "Future" milestone instead of 
REMIND these days, but either is better than closed as a duplicate of the wrong 
bug :-)
Just ran across one...

"WARNING: Illegal character in window name a/b, file nsGlobalWindow.cpp, line
3022"

This warning, and many that go through NS_WARNING or nsDebug.h, should be
displayed to the js console.
> I thought we were leaving bugs open against a "Future"
> milestone instead of REMIND these days

Yes, we are, but I don't think everyone knows that yet.  Some people have a
problem until bug #38105 is fixed.  We might need a remind keyword as well.
Regarding minimal display icon in the iCab browser <http://www.icab.de>, it does 
indeed let you click it to reveal the errors.  The suggested "informational" 
state would be a nice addition to iCab's set of valid/warning/error.  As far as 
a metaphor to express this in the status bar, I think iCab's green/yellow/red 
colored smile/neutral/frown face is about as internationally understandable as 
you can get.  An "informational" state could be expressed as a "word balloon" 
icon, perhaps with an "i" in it.  (Hey it works for MacOS and Windows.)

I agree that _automatically_ emailing the page author of errors would be bad 
(boy I bet it would stimulate some people to fix their pages though!), there 
should be an option (via button) to send the error log to the page author 
indicated in the author LINK tag.  In fact, I think I've suggested before that 
LINK tags should be supported via a tool bar, something else iCab also does, so 
that it would always be easy to email the page author without hunting for a 
hyperlink on the page or finding a contact page on the site.

Mozilla could take several hints from iCab.    
This bug report keeps growing. Here is an excerpt from a latest
*practical* comment curled from bug 41331. I think this is a clear call
to XUL/UI folks to take some action... Many will be satified with this LED
indicator.
------- Additional Comments From rickg@netscape.com 2000-06-02 15:39 -------
We used to have a mode where the parser could report the quality of the page 
back up to the UI, and it would show up as a little red, orange or green LED 
image in the bottom right corner of our UI. That codes long gone, but the parser 
still knows the answer. If UI folks want to reenable the UI, I'll hook up the 
reporting code.
Overall quality indicator request filed as a separate bug (bug 47108). (Shouldn't this bug 
be reopened and futured no that bug 38105 is fixed?)
Filed bug 51484 to use as a tracking bug for various errors that should be 
reported.
reopening and marking Future...
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
*** Bug 57623 has been marked as a duplicate of this bug. ***
Rick, can you tell me where the parser stands as far as reporting errors, and 
how much detail it can provide?  Can you point me to where this sort of thing 
would take place?
*** Bug 65056 has been marked as a duplicate of this bug. ***
One way of showing these error would be through a new View -> "View Page Error" 
menuitem that of cause was controled by a pref, which was default off.
Keywords: beta1nsbeta1
It could be really cool for us webdeveloper if mozilla somehow gave me a 
possibility to report to the console about missing styles.
Lets say you have <span class="nothere">text</span> and the class "notthere" 
didn't exist.
Mozilla could with a hidden pref say to the console:
warning: style "notthere" was not found
javascript console, not console console, please.
That's not an error.  It could be that the class is there to allow for
future extension or for some alternate stylesheet.  CSS selectors match
elements -- they're not commands, and neither are attributes.  Calling
something like that an error (or even a warning) would give a mistaken
impression of how CSS and HTML work.
Should I reopen my original "provide adv users info about missing css styles" 
bug?
I'd prefer if you didn't, because I really don't think we should do something
like that.  It goes against the idea of CSS.  For example, consider something
like the W3C core styles.  Some of those stylesheets may define style rules that
don't match anything in a given document.  Some documents may have elements with
classes, or, for that matter, IDs or element names, that aren't mentioned in the
stylesheet.  Why should classes be special?  They can be used for things other
than causing CSS rules to match, just as element names or other attributes can.
 Or would you want us to warn if there were an element in a document that wasn't
matched by any rule in the document's author stylesheets?
Lets say you have <span class="nothere">text</span> and the class "notthere" 
didn't exist in any of the loaded style sheets.
Mozilla could then say "style notthere was not found"
That's not the way stylesheets work.  CLASS doesn't mean "look for a style".
CSS has class selectors that match elements whose class attribute has as one
of its whitespace-separated parts a certain string.

Why wouldn't we say "style notthere not found" for <SPAN ID="notthere">?  Why
wouldn't we say it for <notthere>?

It's perfectly legitimate to use CLASS to label a group of elements that could
be found by a script, or to mark a group of elements that just have common
semantics.  See http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2,
which says:

  The class attribute, on the other hand, assigns one or more class names to an
  element; the element may be said to belong to these classes. A class name may
  be shared by several element instances. The class attribute has several roles
  in HTML:

    * As a style sheet selector (when an author wishes to assign style
      information to a set of elements).
    * For general purpose processing by user agents.
I agree these are legimitate things, so while it might be beneficial to have a
tool to look for classes in HTML but not CSS, or in CSS but not HTML, it belongs
in the editor, not the browser.
Not sure I understand the last comment. I *never* use the mozilla editor for 
anything. I would just like the browser to be able to give advanced users a 
little more output to make their webfiles behave better.
I think I'll reopen my original bug 65056
The problem is that any "View Page Errors" would be taken by many people as
a statement of whether HTML or CSS was correct or not.  Making legitimate
uses of HTML or CSS show up as errors would discourage those uses, preventing
features of the standards from being used by web authors.
The missing CSS style could be really great for internal XUL stuff. A lot of the
times that a dialog in Mozilla looks weird or plain wrong it's because of some
CSS style error. Sometimes missing styles.
A XUL CSS Style error console could rock!
*** Bug 69016 has been marked as a duplicate of this bug. ***
A lot of stuff i read here would make me very happy. I really like the idea of
the icon that appears, if something is wrong with HTML, CSS..

Also the idea of different error-type seems useful (use of <font> tags =>
warning, non-closed table => error)

the main cause why i'd like such a feature is the (sometimes very useful) error
parser. it helps, if the problem is minimal, but what, if the html-structur is
corrupt at one important place and the side does not show up at all? i have to
read the whole page, searching for a typo... anoying...

please implement that, my skills in programming are sooo poor....
Have you used the W3C's validator? Try ==> http://validator.w3.org/

Works for style too!

Depends on: 65469
Just want to mention bug 28558 (again) 'cause it covers the XUL/chrome part of
that validator/error-reporter thingy...
Summary: View Page Errors wanted → [RFE] View Page Errors
I just opened a new bug (bug 92959) yesterday that looks to be somewhat related
whay everyone is discussing here.  This new bug is specific to JavaScript
errors.  Figured I'd let everyone know.
*** Bug 93892 has been marked as a duplicate of this bug. ***
To make this important bug more easily findable, maybe the subject should be
changed to:

"When bad HTML (or other) code is encountered on web pages (i.e. Page Errors),
inform the user"
*** Bug 93916 has been marked as a duplicate of this bug. ***
I agree about the summary addition and hope this can be resolved before 1.2,
which is the current keyword.
Blocks: 104166
The ability to check for broken links would be nice also. I 
know that there are separate link-checkers available, but
having this integrated with the browser would be exceedingly
convenient.  

Should I file a separate RFE for this, or is it covered
in the scope of this bug?
jonadab:
please file a new bug and cc me (jens-uwe@idealo.de)
The link checker is bug 91388, and the backend is in and working in the editor's
debug menu.

We need a front end for it, though.  I tried to write one but my XUL knowledge
is too primitive.  Please file a new bug to cmanske, and cc me.  Thanks!
I should have made it clear that the existing link checker is for the editor. 
The code could be moved into content and made available to the browser if there
was sufficient demand and the browser and content owners agreed; that would be
yet another new bug (probably mine).  There are several pieces of code which
would have to be moved, not just the JS link checking code itself.
*** Bug 119679 has been marked as a duplicate of this bug. ***
Are 20 votes (as well as 61 votes for the fairly similar 47108) sufficient demand?
changing self to QA so this doesn't get lost (no one is working on this)
Assignee: rickg → nobody
Status: REOPENED → NEW
QA Contact: rickg → choess
The validator should not be targetted at developers only, but also end users. It
would let them know that the reason a page doesn't display correctly is because
of errors in the page. This feature should be highly advertised so as to be a
way to evangelize more developers.

I would suggest a "Validator Icon" in the status bar just to the left of the
Online/Offline indicator. The icon should be a smiley if the page uses valid
HTML/CSS and a frown if it is not.

Clicking on it would bring up a "Validator Console", a popup window listing the
errors in the webpage. It should also have a textbox and a submit button where
users can enter URLs or filenames to validate additional pages if they want to.
I couldn't see anyone mentioning this, but I believe IE actually has this
functionality, at least to some extent.
If the page is malformed (or use something IE doesn't support) it sometimes
shows a yellow triangle with an explamation point, and the message "This page
contains errors, and may not be displayed correctly" in the status bar.

Having this bug resolved I think will be great for everybody :)
The yellow IE triangle is for JS errors, not for HTML errors. I've never seen IE
complaining about <abbr> or <acronym>.

But having this bug resolved I think will be great for everybody :)
I don't know how compatible it is, but Amaya from the W3C has functionality that
tells you about invalid HTML and CSS.  It is available at http://www.w3.org/Amaya.
*** Bug 18165 has been marked as a duplicate of this bug. ***
Component: Viewer App → Browser-General
Summary: [RFE] View Page Errors → [RFE] View Page Errors (Web Development Console)
Whiteboard: [PDT-] → [Hixie-P0][Hixie-2.0]
So, a question:

Should we expand the existing JS console to cover other errors, or do we want a
second error console?  (See also comment 36, although I already have code in the
CSS parser, not currently built, that uses the JS console.)  If we want to use
the JS console, then we should probably rename it from "JavaScript Console" to
"Error Console" or "Page Error console" or something like that.

(I'm asking realistically -- there are a few CSS things that I'd like to start
reporting (like warnings for incorrect MIME type and perhaps multiple preferred
stylesheets with the same title), and I'd also probably like to turn on CSS
parser error reporting at some point in the future.)
How about a warning for broken images?  That would eliminate one of the
arguments for putting alt text in boxes for broken images.
I don't like the re-use of the JS console for this, because it throws all errors
from all windows in together. Could we add an "Errors" tab to the existing Page
Info dialog?
I was about to suggest that too, having tabs in the js console.  It would be
great to have js exeptions occuring in our UI not be mixed with js errors
generated by websites.
The chrome/content separation seems like a good idea.  However, I think throwing
all the errors together does have significant advantages.  Partly, it makes the
errors more prominent since one sees errors from pages one has visited recently,
and thus one can notice errors on pages where one wasn't looking.  Also, if we
tried to go with page-specific errors, we'd have all sorts of thorny issues with
redirects and frames/framesets/iframes and the like, and we'd probably still end
up "losing" a bunch of errors.
Note that the JS console can already filter errors vs. messages vs. warnings. 
So it may make sense to add more possible message types one could filter by....
Stick all errors/warnings/etc into the renamed JS console and then cc the
page-specific errors/warnings/etc to a page info tab.
I say a tabbed "Page Errors" window with tabs for HTML, CSS, JavaScript, and
maybe Other.  There would be checkboxes for Errors, Warnings, and Information.
*** Bug 160090 has been marked as a duplicate of this bug. ***
Depends on: 40945
Part of this would be an icon that appeared in the status bar when an error
occured. Or a smiley vs a frowney.
This blocks Bug #163993 as it has more than 50 on cc list
Blocks: majorbugs
Summary: [RFE] View Page Errors (Web Development Console) → View Page Errors (Web Development Console)
*** Bug 191067 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.2
*** Bug 207914 has been marked as a duplicate of this bug. ***
I think Mozilla should first deal with reporting errors (and warnings) about the
HTML code. That would be already a major and important achievement. The area of
compliance with W3C web standards is where there is so many invalid, incorrectly
authored pages. 
According to W3C, 99% of all webpages (3.2 billions according to google.com) out
there on the web are incorrectly, improperly authored: they would all fail on
HTML validation.

I think users should get to know about a webpage's compliance to widely
recognized, established and accepted web standards of authoring HTML (W3C). From
that report, it would be left entirely to them to do whatever they want: email
the webmaster or do nothing. I'm for a convenient button (or some other GUI) to
email a pre-written, preformatted email to the webmaster: in the final instance,
the user and only him sends that email.

I'm all for a validness icon in the statusbar which when clicked would output a
summary of errors found and warnings about the page. How about bringing up a tab
called "HTML errors report" in View/Page Info?

I believe Mozilla should first start with HTML error reports only and then we'll
see if CSS can be added afterwards. I think having webpage error reports on HTML
will be more than enough to have an incredible impact on the web. Opera 7
already has a different implementation but it is certainly in the same spirit:
right-click/Frame/Validate source <Ctrl>+<Alt>+V

Absence of doctype declaration is an error and it is one of the most frequently
seen one on the web.
> According to W3C, 99% of all webpages

This happens to make HTML error reporting pretty useless, since 99% of all
webpages would flood the console with HTML errors.

It's also very difficult, for HTML, to determine what is "correct" markup and
what is not, since there are so many different cases and exceptions...  Once you
hit the first error, you may as well just stop looking for others, because there
is no error-recovery mechanism in HTML.

> I believe Mozilla should first start with HTML error reports only and then
> we'll see if CSS can be added afterwards. 

CSS, unlike HTML is mostly written more or less correctly and has error-recovery
rules which make the error-reporting not too verbose in most cases.  More
importantly, Mozilla ALREADY has CSS error reporting -- it's just not enabled in
the nightly builds.  It needs a few issues resolved before being enabled, but
it's pretty much in place.  Like any error reporting, though, it hurts performance.

Having a way to invoke the validator on the current page would be an easy
option, though.  Please do file a _separate_ bug on that.
Boris: bug 173496 - validate actual page using W3C validator's file-upload
*** Bug 224531 has been marked as a duplicate of this bug. ***
is there a reason why the CSS errors is only compile with debug.

If you do a debug build You get stuff like this in the JS Console:

Error: Error in parsing value for property 'cursor'.  Declaration dropped.
Source File: http://i.tdconline.dk/tdco/css/hack.css
Line: 10

It comes from nsCSSScanner.cpp but it's in a #ifdef DEBUG block. Why? Doesn
anybody know?
(In reply to comment #103)
> is there a reason why the CSS errors is only compile with debug.

See comment 100 - it needs a few issues resolved before it can be enabled.
Apparently, it's being worked on in bug 65469.

> It comes from nsCSSScanner.cpp but it's in a #ifdef DEBUG block.

Actually, it's in a #ifdef CSS_REPORT_PARSE_ERRORS block, but that name is
conditionally defined in nsCSSScanner.h (line 48) ifdef DEBUG, so the effect is
the same.
(In reply to comment #100)

> It's also very difficult, for HTML, to determine what is "correct" markup and
> what is not, since there are so many different cases and exceptions... 

I think the most common and most damaging ones should be reported in 4 categories:
- absence of doctype declaration or invalid doctype declaration: such detection
 can not hurt performance
- improper/incorrect nesting (incorrect formal syntax): a very common error
which has an impact on layout and the way DHTML scripts can work. iCab, BBedit
and BB Tidy apparently reports this kind of error.
http://scholar.lib.vt.edu/staff/handbook/tasks/syntax_checking/#toperrors
- unknown or illegal or proprietary attributes and/or elements and/or characters
and/or character entities. E.g.: <spacer>
- Bad quality design info: number of nested tables, number of very commonly used
but deprecated elements like <font>, <center> elements. The fact that Opera 7.x
reports number of nested tables and number of <font> elements without any
significant code added should advocate in favor of such report. ICab and BB Tidy
also apparently report usage of <font> and <center>.

 Once you
> hit the first error, you may as well just stop looking for others, because there
> is no error-recovery mechanism in HTML.
> 

Numbers of such 4 categories could be in a tab of a pageInfo and a webpage
quality indicator icon in the statusbar could then be shown.

HTML 4.01 specs might not provide specific error handling implementations, these
same W3C HTML specs nevertheless recommend browsers to notify users about this: 
"We also recommend that user agents provide support for notifying the user of
such errors."
http://www.w3.org/TR/html401/appendix/notes.html#h-B.1

The position of many who commented on this bug reflects this W3C recommendation
here.
This is the code in Opera 7.x's user Style "Show structural elements" which
identifies number of nested tables and <font> elements at the end of the document:

font {counter-increment: fontNo;}
table table {counter-increment: tableNo;}

html:after {
	clear: both !important;
	content: "This page contains " counter(fontNo) " font tags and "
counter(tableNo) " nested tables.";
(...)
}
So I don't see a significant performance issue here.


Depends on: 265871
At this point we basically have a View Page Errors console. It does CSS errors,
JS errors, security issues, etc. If there are specific things that people want
added to the JS Console (like the suggestions at the top of this bug, like "any
HTTP errors like 402s when downloading images or 404s when downloading
stylesheets" or missing glyphs) then people should file new bugs.

I've filed bug 265871 on renaming the console to something more generic.
Status: NEW → RESOLVED
Closed: 24 years ago20 years ago
No longer depends on: 265871
Resolution: --- → WORKSFORME
If the criteria outlined by the reporter in the very first comment are not met,
why is this bug being closed?
Perhaps because Ian *is* the original reporter?  :-)
I don't see a CSS error with the Console...
Product: Browser → Seamonkey
No longer blocks: majorbugs
You need to log in before you can comment on or make changes to this bug.