404 Error Page Status

Feature Description

We want Firefox to override server-supplied 404 error pages in certain cases.  The Firefox 404 page should provide the user with tools we think are more useful to the user for resolving the situation, than the server supplied page.  This includes alternate ("did you mean") URLs derived from the Places database and some pre-loaded search links/controls.  This is being tracked in bug 482874.

Status

Stalled.

The primary sticking point is the review of docshell/resources/content/notFoundError.xhtml.  The network error pages seem to be poorly owned, and it’s not clear to me who to even ask for review.

Final L10N approval is waiting on error page approval.

There are some relatively minor changes to nsDocShell.cpp since Boris Zbarsky’s approval last year.  I don’t think this is a big deal, but it is C++ and it is in docshell, so it probably needs a further look.

There’s one minor outstanding change needed for RTL approval.

Next Steps

A code reviewer for notFoundError.xhtml needs to come forward and help me out. Any suggestions?

If a code reviewer materializes and provides code review, I’ll take care of the necessary code changes.  I have already tried (without success) to try to run down a code reviewer myself, so I need help from someone to do that.

Notes

  • Just a reminder: I am not longer a Mozilla employee, just a volunteer.  I have time right now to work on this feature.  In another month or two this may not be the case.
  • This page has been translated to Belorussian, see http://pc.de/pages/404-error-page-status-be.

 

Parameterizing ENTITY definitions for use in XHTML

It sometimes makes sense to parameterize localizable strings.  For example, in the 404 error page, I need to display a string that looks like:

 "Search {site} for {search-phrase}"

If this string were in a .properties file, it might actually look like:

  "Search %S for %P"

However, since I need to reference the string from a non-privileged XHTML page, I have to use an  ENTITY definition in a ".dtd" file.  The "%" character is not legal in an entity definition, at least not as a literal.  And, if we want to parameterize an entity, we have to roll our own parameterization scheme anyway.  For XHTML files, it turns out the simplest way to do this is to embed XHTML markup in the entity definition, for example:

  "Search <span id='site'/> for <span id='searchPhrase'/>"

It's then trivial to look these elements up using JavaScript and inject the appropriate contents at runtime.  This makes for ugly looking strings, but it's dirt simple to implement.

It occurred to me the other day, that since you can embed references to other entities inside, you could replace the SPAN markup with something like:

  "Search &param.site; for &param.searchPhrase;"

A more complete example might look like:

  <!ENTITY httpFileNotFound.searchSiteFor
      "Search &httpFileNotFound.paramSite; for &httpFileNotFound.paramSearchPhrase;">

where the parameter entity definitions look something like:

  <!ENTITY httpFileNotFound.paramSite "<span id='site'/>">
  <!ENTITY httpFileNotFound.paramSearchPhrase "<span id='searchPhrase'/>">

This looks better to me than having the SPAN elements inlined.  It would look even better if we could dispense with the "httpFileNotFound." qualification and just say:

  <!ENTITY httpFileNotFound.searchSiteFor "Search &paramSite; for &paramSearchPhrase;">

or even:

  <!ENTITY httpFileNotFound.searchSiteFor "Search &SITE; for &SEARCH_PHRASE;">

What do you think?

Insertion of tracing code using the C++ preprocessor

A few months back I got this wild idea that you could insert trace-logging code (not jit-tracing, that's something else) into more or less arbitrary C++ by redefining certain C++ keywords as macros. It turns out that you can, in fact, make this work, at least for certain non-trivial cases. Notably, I've been able to compile an instrumented version of Firefox on OS X using this technique.

I'm not sure whether the technique is generally useful, but given our new focus on crashes and hangs, I thought I'd at least mention it. It's probably not particularly useful for crashes but it may have some utility for debugging hangs. I used an earlier version of this code to debug a Firebug hang (Bug 497028), although in that case I already had a good idea where the problem was and I probably could have used the debugger just as effectively.

Here's the latest tracing code, which I have in a file called "quicktrace.h":

#ifdef __cplusplus    #include <stdio.h>    #include <string.h>    static void QuickTrace(const char *fileName, int lineNumber)    {      if (lineNumber % 100 != 0) return;//    if (strstr(fileName, "/js/") != NULL) return;      fprintf(stderr, ";;; %s %d\n", fileName, lineNumber);    }    #define if     if (QuickTrace(__FILE__, __LINE__), 0) {throw 0;} else if    #define for    if (0) {throw 0;} else for    #define switch if (0) {throw 0;} else switch    #define do     if (0) {throw 0;} else do    #endif

I inserted this code globally by adding the following two lines to my .mozconfig:

export CXXFLAGS="-include /Users/cbartley/dev/mozilla-e/src/quicktrace.h"  ac_add_options --enable-cpp-exceptions

Note that the use of exceptions is non-functional -- the only purpose is to suppress warnings about code paths that don't return a value. If you don't care about the warnings you can dispense with the "throw 0" statements in the header file and the --enable-cpp-exceptions in your .mozconfig file.

Notes:

  • This is unquestionably an abuse of the preprocessor. Don't go down this route unless you really think you know what you're doing.
  • If you really want to create an instrumented build, there are better ways to do it, for example Taras Glek's "Pork" tool. Even using shell scripts and sed to create an instrumented source tree might be a better choice.
  • I think the code in this post will probably work on any GCC-based build, but I don't know for sure. As far as I can tell, Visual C++ doesn't have an equivalent of GCC's "-include" flag and I haven't tried this on Windows.
  • To do useful trace logging you really want a global implementation of the "QuickTrace" function. This is somewhat challenging for Firefox because of the way it's linked. I'm leaving this part as an exercise to the reader.
  • The Firefox build actually compiles some tools from source and then uses those tools later on in the build. This means that if you're going to generate logging from the trace function you do not want to send it to stdout.
  • It might make more sense to include the quicktrace.h header file from another very commonly used header file. This might be the only option on Windows anyway.
  • I think it should be pretty easy to build an instrumented Firefox using this approach and the Try server. I haven't actually attempted this yet, though.
  • If you generate output every time the trace function is called, it will be unbearably slow.
  • You can't generate a proper call graph using this approach, although with some post-processing you could probably get a useful approximation of a call graph.
  • There's probably some caveat that I forgot to mention.

404 Error Page Status

Feature Description

We want Firefox to override server-supplied 404 error pages in certain cases.  The Firefox 404 page should provide the user with tools we think are more useful to the user for resolving the situation, than the server supplied page.  This includes alternate ("did you mean") URLs derived from the Places database and some pre-loaded search links/controls.  This is being tracked in bug 482874.

Status

On hold for the week while I worked on higher priority Firefox 3.6 stuff.  There are still some L10N issues to address and some general touch up before I can roll a new patch.

Next Steps

Address remaining issues raised in last round of code review and get another patch out.  This will probably have to wait until after the Firefox 3.6 code freeze that's coming up.

Notes
  • The feature is controlled by a pref so it can be turned off.
  • Webmasters who don't want their 404 error pages to be overridden may have to add padding to their 404 error pages.  However, since IE and Google Chrome are already overriding 404 error pages using a similar size test, webmasters already need to do this.
  • We want to provide a way for the user to see the original 404 error page, but that's not in this patch.

Troubleshooting Information (AKA about:support) Status

Feature Description

Mozilla's support organization has a longstanding request for a Firefox diagnostic page that can provide information about the user's Firefox installation such as which extensions are installed and what prefs have been modified.  The result is the "Troubleshooting Information" page, which is also accessible by typing "about:support" in the location bar.  This feature is fairly constrained for 3.6 since we didn't start work on it until a few days before string freeze. 

Screenshot: https://bug367596.bugzilla.mozilla.org/attachment.cgi?id=400664
Project Page: Firefox/Projects/about:support
Bug: 367596 -  (about:support) [RFE] Create a support info page/lister.

Status

  • Landed!  Troubleshooting Information is now available in both trunk and Firefox 3.6 nightlies.
Next Steps
  •  Bug 518601 -  Troubleshooting Information page should not allow copy-and-paste of the profile directory.  This is a potential security issue and needs to be addressed before Firefox 3.6 ships.
  •  Bug 516616 -  Add an "Installation History" section to about:support.   Nice to have for 3.6.
  •  Bug 516617 -  Add an "Update History" section to about:support.  Nice to have for 3.6.

Notes
  • This is a starting point, not an ending point.  We can extend the functionality for Firefox 3.7.

Troubleshooting Information (AKA about:support) Status

Feature Description

Mozilla's support organization has a longstanding request for a Firefox diagnostic page that can provide information about the user's Firefox installation such as which extensions are installed and what prefs have been modified.  The result is the "Troubleshooting Information" page, which is also accessible by typing "about:support" in the location bar.  This feature is fairly constrained for 3.6 since we didn't start work on it until a few days before string freeze. 

Screenshot: https://bug367596.bugzilla.mozilla.org/attachment.cgi?id=400664
Project Page: Firefox/Projects/about:support
Bug: 367596 -  (about:support) [RFE] Create a support info page/lister.

Status

  • The implementation went through seven or so revisions in the days just prior to Firefox 3.6 string freeze.
  • Current page design includes "Application Basics" (App name, version, profile directory, etc.), "Installed Extensions", and "Modified Preferences".
  • Strings for all of the above were landed on trunk and the 1.9.2 (Firefox 3.6) branch in a strings-only patch.  This patch also included strings for "Installation History" and "Update History" sections, in hopes that we can get those features in as well for Firefox 3.6 (Bugs 516616 and 516617).
  • Discovered a performance bug in the FUEL preferences API (Bug 517312).  I've rewritten part of this code to use the lower-level preference API, which avoids the bug and is just much speedier all around.
Next Steps

Address the remaining issues from the last round of code review, and see if we can get the main patch landed.

Notes
  • This is a starting point, not an ending point.  We can extend the functionality for Firefox 3.7.

404 Error Page Status

Feature Description

We want Firefox to override server-supplied 404 error pages in certain cases.  The Firefox 404 page should provide the user with tools we think are more useful to the user for resolving the situation, than the server supplied page.  This includes alternate ("did you mean") URLs derived from the Places database and some pre-loaded search links/controls.  This is being tracked in bug 482874.

Status

Final work was delayed while I worked on about:support/Troubleshooting Information.  Since then I've rewritten the Places part of the patch in JavaScript as requested in the most recent code review.  I still have some L10N issues to address and some general touch up.

Next Steps

    Pinky: "Gee Brain, what do you want to do next week?"
    The Brain: "The same thing we do every week, Pinky—try to land this patch!"

Notes
  • The feature is controlled by a pref so it can be turned off.
  • Webmasters who don't want their 404 error pages to be overridden may have to add padding to their 404 error pages.  However, since IE and Google Chrome are already overriding 404 error pages using a similar size test, webmasters already need to do this.
  • We want to provide a way for the user to see the original 404 error page, but that's not in this patch.

404 Error Page Status

Feature Description

We want Firefox to override server-supplied 404 error pages in certain cases.  The Firefox 404 page should provide the user with tools we think are more useful to the user for resolving the situation, than the server supplied page.  This includes alternate ("did you mean") URLs derived from the Places database and some pre-loaded search links/controls.  This is being tracked in bug 482874.

Status

Found and worked around an SQLite bug (Bug 514291).  Did some performance analysisis, suggestions query tweaking, etc.

Latest patch is attached to the bug and review is requested.

A try server build is available
Next Steps
  • If the reviews come back positive, get it landed.
  • If the reviews raise issues, address them ASAP.
Notes
  • The feature is controlled by a pref so it can be turned off.
  • Webmasters who don't want their 404 error pages to be overridden may have to add padding to their 404 error pages.  However, since IE and Google Chrome are already overriding 404 error pages using a similar size test, webmasters already need to do this.
  • We want to provide a way for the user to see the original 404 error page, but that's not in this patch.

404 Error Page Status

Feature Description

We want Firefox to override server-supplied 404 error pages in certain cases.  The Firefox 404 page should provide the user with tools we think are more useful to the user for resolving the situation, than the server supplied page.  This includes alternate ("did you mean") URLs derived from the Places database and some pre-loaded search links/controls.  This feature is being tracked in bug 482874.

Status

Almost ready to go.  Notable progress this week:
  • The docshell changes have r+ from bz with just a few changes, most of which I've already made.
  • Axel has provided some feedback on localization.
  • Johnath has provided feedback on the XHTML.
  • Marco has provided some feedback about the Places changes.  Notably he points out that query performance could be an issue on large databases.
  • David Dahl has provided me with a "max_places" test database.  The bad news is the URL suggestions query can take ~30 seconds to run against this database.  The good news is that a very simple length-check guard in the query can make a big difference.
Next Steps
  • Address  the localization changes Axel raised, and then get formal L10N review.
  • Address the performance issues in the URL suggestions query.  (Probably just a LIMIT-based approach for the initial patch)
  • Get a formal review of Places changes (Dietrich did an informal review a few weeks ago).
  • Get a final UI review.
  • Make sure all the parts of the patch have r+ from the various parties.
  • Land the thing.

404 Error Page Status

Feature Description

We want Firefox to override server-supplied 404 error pages in certain cases.  The Firefox 404 page should provide the user with tools we think are more useful to the user for resolving the situation, than the server supplied page.  This includes alternate ("did you mean") URLs derived from the Places database and some pre-loaded search links/controls.

Status

The newest patch is almost ready for review.

This patch is mostly focused on making the code right, but there are a couple of functional changes:
  • The Firefox 404 error page is now pref-controlled.  There's a pref to turn it on and off, and a pref to limit which server-supplied 404 pages we'll override.  Currently we will only override server 404 pages of 512 bytes or less.
  • We're dropping the background image for now.


Next Steps

  • Complete the patch and get it in for review.
  • Blog about it.

Notes

  • This feature is being tracked by Bug 482874 - Provide a friendlier/more useful alternative when the user encounters a 404 error page.

Edit: Added Notes section.