Closed
Bug 6211
Opened 25 years ago
Closed 20 years ago
View Page Errors (Web Development Console)
Categories
(SeaMonkey :: General, enhancement, P3)
SeaMonkey
General
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]
Comment 1•25 years ago
|
||
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.
Reporter | ||
Comment 2•25 years ago
|
||
[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...
Reporter | ||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 4•25 years ago
|
||
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.
Comment 5•25 years ago
|
||
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?
Comment 6•25 years ago
|
||
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.
Reporter | ||
Comment 7•25 years ago
|
||
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.
Comment 8•25 years ago
|
||
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).
Comment 9•25 years ago
|
||
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.
Comment 10•25 years ago
|
||
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.
Comment 11•25 years ago
|
||
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.
Comment 12•25 years ago
|
||
I split off the auto-email issue as bug #13011.
Comment 13•25 years ago
|
||
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.
Comment 14•25 years ago
|
||
As well as preventing spurious bug reporting.
Comment 15•25 years ago
|
||
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
Updated•25 years ago
|
Summary: View Markup Errors wanted → View Page Errors wanted
Comment 16•25 years ago
|
||
Refined description a bit to reflect the more general possibilities of this
report.
Comment 17•25 years ago
|
||
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.
Comment 18•25 years ago
|
||
Updating QA Contact.
Comment 19•25 years ago
|
||
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.
Comment 20•25 years ago
|
||
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!).
Comment 21•25 years ago
|
||
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
Comment 22•25 years ago
|
||
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 → ---
Comment 24•25 years ago
|
||
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.
Comment 25•25 years ago
|
||
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 ago → 25 years ago
Resolution: --- → REMIND
Comment 26•25 years ago
|
||
*** part of bug #28558 was stated as a dupe of this one.
Comment 27•25 years ago
|
||
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.
Comment 28•25 years ago
|
||
*** Bug 29404 has been marked as a duplicate of this bug. ***
Comment 29•25 years ago
|
||
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.
Comment 30•25 years ago
|
||
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.
Comment 31•25 years ago
|
||
> 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.
Comment 32•25 years ago
|
||
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.
Comment 33•25 years ago
|
||
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]
Comment 34•25 years ago
|
||
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.
Comment 35•25 years ago
|
||
Minimal display is cool, but you should be able to double-click it to see the
errors. Otherwise, how will the feature be debugged?
Comment 36•24 years ago
|
||
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
Comment 37•24 years ago
|
||
So, mccabe, does this distinguish info, warnings and errors?
Comment 38•24 years ago
|
||
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 → ---
Comment 39•24 years ago
|
||
Marking as dup of js console bug.
*** This bug has been marked as a duplicate of 4263 ***
Status: REOPENED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → DUPLICATE
Updated•24 years ago
|
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Target Milestone: --- → Future
Comment 40•24 years ago
|
||
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
Comment 41•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → REMIND
Comment 42•24 years ago
|
||
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 :-)
Comment 43•24 years ago
|
||
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.
Comment 44•24 years ago
|
||
> 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.
Comment 45•24 years ago
|
||
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.
Comment 46•24 years ago
|
||
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.
Comment 48•24 years ago
|
||
Filed bug 51484 to use as a tracking bug for various errors that should be
reported.
Comment 49•24 years ago
|
||
reopening and marking Future...
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
Comment 50•24 years ago
|
||
*** Bug 57623 has been marked as a duplicate of this bug. ***
Comment 51•24 years ago
|
||
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?
Comment 52•24 years ago
|
||
*** Bug 65056 has been marked as a duplicate of this bug. ***
Comment 53•24 years ago
|
||
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.
Comment 54•24 years ago
|
||
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
Comment 55•24 years ago
|
||
javascript console, not console console, please.
Comment 56•24 years ago
|
||
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.
Comment 57•24 years ago
|
||
Should I reopen my original "provide adv users info about missing css styles"
bug?
Comment 58•24 years ago
|
||
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?
Comment 59•24 years ago
|
||
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"
Comment 60•24 years ago
|
||
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.
Comment 61•24 years ago
|
||
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.
Comment 62•24 years ago
|
||
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
Comment 63•24 years ago
|
||
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.
Comment 64•24 years ago
|
||
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!
Comment 65•24 years ago
|
||
*** Bug 69016 has been marked as a duplicate of this bug. ***
Comment 66•24 years ago
|
||
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....
Comment 67•24 years ago
|
||
Have you used the W3C's validator? Try ==> http://validator.w3.org/
Works for style too!
Updated•24 years ago
|
Keywords: mozilla1.2
Comment 68•24 years ago
|
||
Just want to mention bug 28558 (again) 'cause it covers the XUL/chrome part of
that validator/error-reporter thingy...
Updated•23 years ago
|
Summary: View Page Errors wanted → [RFE] View Page Errors
Comment 69•23 years ago
|
||
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.
Comment 70•23 years ago
|
||
*** Bug 93892 has been marked as a duplicate of this bug. ***
Comment 71•23 years ago
|
||
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"
Comment 72•23 years ago
|
||
*** Bug 93916 has been marked as a duplicate of this bug. ***
Comment 73•23 years ago
|
||
I agree about the summary addition and hope this can be resolved before 1.2,
which is the current keyword.
Comment 74•23 years ago
|
||
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?
Comment 75•23 years ago
|
||
jonadab:
please file a new bug and cc me (jens-uwe@idealo.de)
Comment 76•23 years ago
|
||
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!
Comment 77•23 years ago
|
||
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.
Comment 78•23 years ago
|
||
*** Bug 119679 has been marked as a duplicate of this bug. ***
Comment 79•23 years ago
|
||
Are 20 votes (as well as 61 votes for the fairly similar 47108) sufficient demand?
Comment 80•23 years ago
|
||
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
Comment 81•23 years ago
|
||
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.
Comment 82•23 years ago
|
||
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 :)
Comment 83•23 years ago
|
||
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 :)
Comment 84•23 years ago
|
||
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.
Comment 85•22 years ago
|
||
*** Bug 18165 has been marked as a duplicate of this bug. ***
Reporter | ||
Updated•22 years ago
|
Component: Viewer App → Browser-General
Summary: [RFE] View Page Errors → [RFE] View Page Errors (Web Development Console)
Whiteboard: [PDT-] → [Hixie-P0][Hixie-2.0]
Comment 86•22 years ago
|
||
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.)
Comment 87•22 years ago
|
||
How about a warning for broken images? That would eliminate one of the
arguments for putting alt text in boxes for broken images.
Comment 88•22 years ago
|
||
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?
Comment 89•22 years ago
|
||
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.
Comment 90•22 years ago
|
||
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.
Comment 91•22 years ago
|
||
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....
Reporter | ||
Comment 92•22 years ago
|
||
Stick all errors/warnings/etc into the renamed JS console and then cc the
page-specific errors/warnings/etc to a page info tab.
Comment 93•22 years ago
|
||
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.
Comment 94•22 years ago
|
||
*** Bug 160090 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 95•22 years ago
|
||
Part of this would be an icon that appeared in the status bar when an error
occured. Or a smiley vs a frowney.
Comment 96•22 years ago
|
||
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)
Comment 97•22 years ago
|
||
*** Bug 191067 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Keywords: mozilla1.2
Comment 98•21 years ago
|
||
*** Bug 207914 has been marked as a duplicate of this bug. ***
Comment 99•21 years ago
|
||
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.
Comment 100•21 years ago
|
||
> 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.
Comment 101•21 years ago
|
||
Boris: bug 173496 - validate actual page using W3C validator's file-upload
Comment 102•21 years ago
|
||
*** Bug 224531 has been marked as a duplicate of this bug. ***
Comment 103•21 years ago
|
||
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?
Comment 104•21 years ago
|
||
(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.
Comment 105•20 years ago
|
||
(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.
Comment 106•20 years ago
|
||
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.
Reporter | ||
Comment 107•20 years ago
|
||
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 ago → 20 years ago
No longer depends on: 265871
Resolution: --- → WORKSFORME
Comment 108•20 years ago
|
||
If the criteria outlined by the reporter in the very first comment are not met,
why is this bug being closed?
Comment 109•20 years ago
|
||
Perhaps because Ian *is* the original reporter? :-)
Comment 110•20 years ago
|
||
I don't see a CSS error with the Console...
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•