Closed Bug 6211 Opened 26 years ago Closed 20 years ago

View Page Errors (Web Development Console)

Categories

(SeaMonkey :: General, enhancement, P3)

Product:
SeaMonkey
Component:
General
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: ian, Unassigned)

References

(
URL
)

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: 26 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: 26 years ago → 25 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.
URL: http://icab.de/smile.html
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 ago → 25 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: 25 years ago → 25 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: beta1 → nsbeta1
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: 25 years ago → 20 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.