662901 - about:support empty after bug 660732

Status: VERIFIED FIXED

(Firefox :: General, defect)

Description

[Jim Jeffery not reading bug-mail 1/2/11]

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="http://www.w3.org/1999/xhtml">&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

[Justin Dolske [:Dolske]]

What addons do you have installed? Can you get to the generated page with DOMi to see which TD is doing this?

Comment 2

[Jim Jeffery not reading bug-mail 1/2/11]

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

[Gary [:streetwolf52]]

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

[Gary [:streetwolf52]]

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

[Blair McBride [:Unfocused] (UNAVAILABLE)]

Attachment: 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

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

Both this bug and bug 663132 have patches to deal with this.

Probably only one should go forward.

Comment 7

[Dave Townsend [:mossop]]

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 10

[:Gavin Sharp [email: [e-mail]]]

See bug 663132 comment 9 - I don't think that fix is wrong, but I prefer an even more conservative approach.

Comment 11

[(no longer active)]

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

[:Gavin Sharp [email: [e-mail]]]

That's what I said in bug 663132 comment 9! :)

Comment 13

[(no longer active)]

(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 15

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

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":
print.printer_CutePDF_Writer.print_footerleft
print.printer_CutePDF_Writer.print_footerright
print.printer_CutePDF_Writer.print_headerleft
print.printer_CutePDF_Writer.print_headerright
print.printer_HP_Deskjet_D2600_series.print_footerleft
print.printer_HP_Deskjet_D2600_series.print_footerright
print.printer_HP_Deskjet_D2600_series.print_headerleft
print.printer_HP_Deskjet_D2600_series.print_headerright

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

[Gary [:streetwolf52]]

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

[Paul [pwd]]

(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

[Dave Townsend [:mossop]]

Fixed by backing out bug 660732

Comment 19

[Tony Mechelynck [:tonymec]]

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. http://hg.mozilla.org/mozilla-central/pushloghtml?changeset=84189d94f01a ), and paste your user-agent (and, if you have Nightly Tester Tools installed, your 14-digit "build ID" datestamp) in a comment.