Closed
Bug 662901
Opened 13 years ago
Closed 13 years ago
about:support empty after bug 660732
Categories
(Firefox :: General, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: jmjjeffery, Assigned: Unfocused)
References
(Blocks 1 open bug)
Details
(Keywords: regression)
Attachments
(1 file)
2.35 KB,
patch
|
mossop
:
review-
|
Details | Diff | Splinter Review |
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
Reporter | ||
Updated•13 years ago
|
Comment 1•13 years ago
|
||
What addons do you have installed? Can you get to the generated page with DOMi to see which TD is doing this?
Reporter | ||
Comment 2•13 years ago
|
||
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•13 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•13 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
Assignee | ||
Comment 5•13 years ago
|
||
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.
Both this bug and bug 663132 have patches to deal with this. Probably only one should go forward.
Comment 7•13 years ago
|
||
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-
Updated•13 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Updated•13 years ago
|
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 10•13 years ago
|
||
See bug 663132 comment 9 - I don't think that fix is wrong, but I prefer an even more conservative approach.
Status: REOPENED → ASSIGNED
Comment 11•13 years ago
|
||
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•13 years ago
|
||
That's what I said in bug 663132 comment 9! :)
Comment 13•13 years ago
|
||
(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. :-)
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•13 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•13 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.
Comment 18•13 years ago
|
||
Fixed by backing out bug 660732
Status: ASSIGNED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED
Comment 19•13 years ago
|
||
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.
Description
•