Closed
Bug 318278
Opened 20 years ago
Closed 12 years ago
Locales with parsing errors should not break extensions
Categories
(Firefox :: General, defect)
Firefox
General
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: bugzilla, Unassigned)
Details
This is coming up time and time again on the support forums (especially with new Firefox releases) and I think a comprehensive fix is required. Apologies for this being assigned to Firefox/General, I'm not sure where else to file this right now.
In a nutshell, the problem is that most extension developers don't implement comprehensive testing schemes for locales to ensure compatibility at each release. The net result is that users can be faced with an intimidating XML parsing error when they upgrade either Firefox or their extension or both.
The solution as I see it would be to modify the code that parses locale files and have it fall back to en-US (or another sensible default locale for that extension) if a parsing error occurs. This has the advantage that it's graceful, but the disadvantage that it could be confusing.
The other plausible solution I can think of is to log an error to the JavaScript console and have the extension fail to load entirely.
| Reporter | ||
Comment 1•20 years ago
|
||
Nominating for 2.0 way ahead of the game. Is anyone able to take this on?
Flags: blocking-aviary2?
Comment 2•20 years ago
|
||
Benjamin, is locale fallback feasible for branch or is this Fx3 fodder?
Comment 3•20 years ago
|
||
I don't think this is something that is 2.0 fodder, mainly because we'd have to go all the way down to the XML parser level. There is a vague possibility that we could do this without changing any interfaces, but it's not something I'd like to try.
We *could* implement some sort of "detection" mechanism for 2.0 that says "I noticed that this extension has XML parsing errors, would you like me to disable it for you."
Morph this bug as you see fit.
Comment 4•20 years ago
|
||
This would be a nice to have, but I don't think its a blocker at present. Would take a branch-safe patch.
Flags: blocking-aviary2? → blocking-aviary2-
I also have a parsing problem. XML lines commented out with # with no space causes errors, and prevents the page from loading correctly, also impacting extensions, plugins, and other features from operating correctly. I don't think it is a big problem to fix. Find the parser code (hopefully you have only one parser) and add "#" to the single character terminator string. Thus any time # is found it is returned as a single character token. This will fix one of the main bugs, and reduce a lot of other errors.
message in console:
Error: Error in parsing value for property 'font-size'. Declaration dropped.
Source File: https://a248.e.akamai.net/sec.yimg.com/lib/cs/ycs_aheader2.css
Line: 4
first few lines including line with the error:
body { margin: 0px 4px 10px 4px; }
#ycs_nma div, #ycs_nma table, #ycs_nma td { text-align: left; }
#ycs_nma div, #ycs_nma table, #ycs_nma td, #ycs_nma input { font-family: Arial, Helvetica, sans-serif; font-size: small; font-size: expression(document.all ? "x-small" : "small"); }
#ycs_nma table, #ycs_nma tr, #ycs_nma td { margin: 0px; padding: 0px; }
#ycs_nma img { border: 0px; }
Comment 6•12 years ago
|
||
Unclear if this is still a problem nowadays (~7 year bug, and I'd expect more reports about this if it's still affecting users)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•