The default bug view has changed. See this FAQ.

about:support empty after bug 660732

VERIFIED FIXED

Status

()

Firefox
General
--
major
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: Jim Jeffery not reading bug-mail 1/2/11, Assigned: Unfocused)

Tracking

(Blocks: 1 bug, {regression})

Trunk
x86
Windows 7
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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
Blocks: 660732
Severity: normal → major
Keywords: regression
No longer blocks: 660732
Blocks: 660732
What addons do you have installed? Can you get to the generated page with DOMi to see which TD is doing this?
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

6 years ago
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

6 years ago
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
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.
Assignee: nobody → bmcbride
Status: NEW → ASSIGNED
Attachment #538166 - Flags: review?(gavin.sharp)
Both this bug and bug 663132 have patches to deal with this.

Probably only one should go forward.
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)
Attachment #538166 - Flags: review?(gavin.sharp) → review-
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 663132
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Duplicate of this bug: 663132
See bug 663132 comment 9 - I don't think that fix is wrong, but I prefer an even more conservative approach.
Status: REOPENED → ASSIGNED
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.
That's what I said in bug 663132 comment 9! :)
(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.  :-)

Updated

6 years ago
Duplicate of this bug: 663589
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

6 years ago
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

6 years ago
(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.
Fixed by backing out bug 660732
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.