Last Comment Bug 662901 - about:support empty after bug 660732
: about:support empty after bug 660732
: regression
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: Trunk
: x86 Windows 7
-- major with 2 votes (vote)
: ---
Assigned To: Blair McBride [:Unfocused] (UNAVAILABLE)
: 663132 663589 (view as bug list)
Depends on:
Blocks: 660732
  Show dependency treegraph
Reported: 2011-06-08 12:36 PDT by Jim Jeffery not reading bug-mail 1/2/11
Modified: 2011-06-13 18:51 PDT (History)
17 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Patch v1 (2.35 KB, patch)
2011-06-08 20:27 PDT, Blair McBride [:Unfocused] (UNAVAILABLE)
dtownsend: review-
Details | Diff | Splinter Review

Description User image Jim Jeffery not reading bug-mail 1/2/11 2011-06-08 12:36:38 PDT
about:support is empty after the landing of bug 660732 
in cset: 20110608040738 010b73990286

Was okay before that landed, also seeing in Console2 Error console:

Extensions, Modified Prefs and Graphics are all empty only the banner bar for each category shows.  

These errors in Console2
Error: not well-formed
Source code:
<td xmlns="">&PT</

Error: An invalid or illegal string was specified = NS_ERROR_DOM_SYNTAX_ERR
Source file: chrome://global/content/aboutSupport.js
Line: 382
Comment 1 User image Justin Dolske [:Dolske] 2011-06-08 16:02:31 PDT
What addons do you have installed? Can you get to the generated page with DOMi to see which TD is doing this?
Comment 2 User image Jim Jeffery not reading bug-mail 1/2/11 2011-06-08 16:11:26 PDT
FlashBlock, Console2 & ForecastFox - I tend to be very minimalist when testing.

Sorry, but I have no idea what I'm looking at with Inspector or what TD does..
Comment 3 User image Gary [:streetwolf] 2011-06-08 16:22:30 PDT
I can confirm this.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110608 Firefox/7.0a1 - Build ID: 20110608132439
Comment 4 User image Gary [:streetwolf] 2011-06-08 16:38:01 PDT
function createElement(tagName, content, opt_class) {
  let elem = document.createElement(tagName);
  elem.innerHTML = content;
  elem.className = opt_class || "";
  return elem;

This seems to be where the error console is pointing to.  elem.innerHTML = content; is line 382
Comment 5 User image Blair McBride [:Unfocused] (UNAVAILABLE) 2011-06-08 20:27:09 PDT
Created attachment 538166 [details] [diff] [review]
Patch v1

Same safety-net as the original patch in bug 660732, except it's for all cases where it can use output from errorMessageForFeature() - instead of just the one where we expect to see the message with a link.
Comment 6 User image Wes Kocher (:KWierso) 2011-06-09 08:39:28 PDT
Both this bug and bug 663132 have patches to deal with this.

Probably only one should go forward.
Comment 7 User image Dave Townsend [:mossop] 2011-06-09 08:44:52 PDT
Comment on attachment 538166 [details] [diff] [review]
Patch v1

As far as I can tell content is always a string with no markup in it, so just using textContent everywhere makes more sense (as in the patch in bug 663132)
Comment 8 User image Dave Townsend [:mossop] 2011-06-09 08:45:40 PDT

*** This bug has been marked as a duplicate of bug 663132 ***
Comment 9 User image :Gavin Sharp [email:] 2011-06-09 11:26:32 PDT
*** Bug 663132 has been marked as a duplicate of this bug. ***
Comment 10 User image :Gavin Sharp [email:] 2011-06-09 11:27:13 PDT
See bug 663132 comment 9 - I don't think that fix is wrong, but I prefer an even more conservative approach.
Comment 11 User image :Ehsan Akhgari 2011-06-09 14:37:58 PDT
OK, I don't like this patch at all.  It just moves the problem to a future date.  innerHTML should not really be used in XHTML documents, unless we make sure that the string passed to it is a valid XML fragment, which is not trivial.  We should just use the DOM APIs in my opinion.
Comment 12 User image :Gavin Sharp [email:] 2011-06-09 14:55:01 PDT
That's what I said in bug 663132 comment 9! :)
Comment 13 User image :Ehsan Akhgari 2011-06-09 15:08:39 PDT
(In reply to comment #12)
> That's what I said in bug 663132 comment 9! :)

Precisely.  And that is why I should read my bugmail completely before saying stupid things.  :-)
Comment 14 User image Philip Chee 2011-06-11 11:11:59 PDT
*** Bug 663589 has been marked as a duplicate of this bug. ***
Comment 15 User image Wes Kocher (:KWierso) 2011-06-11 22:06:46 PDT
FWIW, I went in and edited aboutSupport.js locally, wrapping the elem.innerHTML = content; line in a try-catch block, and if it catches an error, it replaces that line with elem.innerHTML = "some arbitrary string";

When I did this, about:support loaded completely, and the following modified preferences had the content as "some arbitrary string":

If I look up those prefs in about:config, the "headerright" prefs are all set to "&U", the "headerleft" prefs are all set to "&T", the "footerleft" prefs are all "&PT", and the "footerright" prefs are all set to "&D".
Comment 16 User image Gary [:streetwolf] 2011-06-12 07:45:13 PDT
No offense to anyone but is this really that difficult to fix?  IMO it should have been fixed by now as it's a regression.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110612 Firefox/7.0a1 - Build ID: 20110612030726
Comment 17 User image Paul [pwd] 2011-06-12 07:53:04 PDT
(In reply to comment #16)

As the thread states, band-aiding the problem isn't an issue but it would only be a temp fix destined to reappear in the future. Thus efforts are being put into actually fixing the problem in such a manner that it won't reoccur as a future issue down the line.
Comment 18 User image Dave Townsend [:mossop] 2011-06-12 08:50:53 PDT
Fixed by backing out bug 660732
Comment 19 User image Tony Mechelynck [:tonymec]. (NEEDINFO me if you want my attention) 2011-06-13 18:51:29 PDT
Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110613 Firefox/7.0a1 SeaMonkey/2.4a1 ID:20110613003111

about:support is now normal again. I'm setting this VERIFIED on the assumption that this fix is at a "deep enough" level of backend to apply all over the board. People, if you want to REOPEN, please first make sure that you're seeing the bug in a trunk build (i.e. rv:7.0a1) whose source was pulled after Sun Jun 12 08:47:49 2011 -0700 (when the backout was pushed, cf. ), and paste your user-agent (and, if you have Nightly Tester Tools installed, your 14-digit "build ID" datestamp) in a comment.

Note You need to log in before you can comment on or make changes to this bug.