Closed Bug 636689 Opened 13 years ago Closed 13 years ago

Rename the HTML5 parser pref in order to reset it for everyone who has flipped it during the beta cycle

Categories

(Core :: DOM: HTML Parser, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- -

People

(Reporter: hsivonen, Assigned: hsivonen)

References

Details

(Keywords: addon-compat, Whiteboard: [needs approval and then landing once either bug 627729 or bug 636690 moves to FIXED])

Attachments

(2 files, 1 obsolete file)

From bug 627729 comment 107:
> (In reply to comment #106)
> We're not officially telling users to disable the parser. In fact, I've
> deliberately avoided giving that advice where I find it, instead opting to tell
> users to try to convince Microsoft to hurry the fix.  However as with all
> forums and such help sites, the steps that ACTUALLY WORK are the ones that will
> get all of the +1s and rise to the top.
> 
> So, yes, those users get a little screwed unless we can proactively re-enable
> html5 for them in a later release, but there are really no other reasonable
> workarounds.  Telling people to install IETab and figure it out isn't really
> viable -- even beta users don't want to go through that kind of hassle when the
> next post down says "change a pref" and has a 100% success rate.

An easy and effective solution to the problem of users having the HTML5 parser disabled because they've flipped the pref prior to Firefox 4 final for whatever reason but particularly due to the Hotmail reload issue would be renaming the pref in Firefox 4. This way, the pref would reset to HTML5 parser enabled for everyone.

Also, as long as we aren't taking the pref away, it should show in about:support, since the pref has a notable impact on how the product behaves.
Attachment #515037 - Flags: review?(bzbarsky)
Nominating as a blocker due reason stated in comment 0.
blocking2.0: --- → ?
Whiteboard: [has patch][needs review]
What about extension compatibility?
Keywords: late-compat
(In reply to comment #3)
> What about extension compatibility?

Extensions should have no business flipping this pref. Do we know of extensions that flip this pref? If so, why do they flip it?

The only even remotely legitimate reason for an extension to flip this pref would be aiding in debugging, but it seems kinda silly to have an extension to that for debugging when the people who need to flip this for debugging could do so manually in about:config.
They may not actually flip it, they may just be checking it's value. There's no knowing what extensions will do. Changing a pref this late in the cycle *may* cause some extension issues, not sure if and how much, just thought I'd make note of it.
Missed some tests.
Attachment #515037 - Attachment is obsolete: true
Attachment #515037 - Flags: review?(bzbarsky)
Whiteboard: [has patch][needs review]
Personally, I think we should make this change, if people have actually been suggesting this pref be flipped on anything other than a temporary testing basis.  :(
We can evaluate an approval, but there is no way this blocks release.
blocking2.0: ? → -
Comment on attachment 515082 [details] [diff] [review]
Rename the pref, make it show in about:support, v2

I personally think we should take this, if beta testers still have this pref changed I think we should force them to re-think that decision so that they can let us know if the reasons they flipped the pref in the first place gets brought to our attention (again, if so needed).
Attachment #515082 - Flags: review+
Attachment #515082 - Flags: approval2.0?
Depends on: 636690
Whiteboard: [needs landing once either bug 627729 or bug 636690 moves to FIXED]
This patch doesn't have conflicting diff context in case we decide not to land the patch for bug 627729.
Whiteboard: [needs landing once either bug 627729 or bug 636690 moves to FIXED] → [needs approval and then landing once either bug 627729 or bug 636690 moves to FIXED]
I think that the aboutSupport.js needs to be checked in separately if this patch doesn't get approval. The risk is negligible and it will be very useful in diagnosing user support issues, especially if more and more people are following the advice of "just set html5.enable to false to fix it".
WRT about:support, see bug 593443 (which already mentions this one).

A much simpler patch would be to just reset the existing pref on update, rather than renaming it. It'd have a much lower impact and would avoid the potential issue of extensions checking this pref for whatever reason as brought up by Natch above. Is there an easy way to just reset it on upgrade to Firefox 4?
Comment on attachment 515082 [details] [diff] [review]
Rename the pref, make it show in about:support, v2

I double checked the changes here and I think we should take this for 2.0. a+
Attachment #515082 - Flags: approval2.0? → approval2.0+
Landed:

http://hg.mozilla.org/mozilla-central/rev/41ce2958892a
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Shouldn't this land "once either bug 627729 or bug 636690 moves to FIXED"?
Bug 627729 has been landed, the bug is just not marked FIXED because it may still be backed out.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: