190358 - rename disable_xul_cache pref and remove from debug UI

Status: RESOLVED WONTFIX

(Core :: XUL, defect)

Description

[John Morrison]

Disabling the XUL cache via pref "nglayout.debug.disable_xul_cache" is a 
leftover backdoor for XUL developers to use. 

While I think there is a good argument to be made for completely removing the 
ability to run without the xul cache, timeless and shaver have argued against
that in the past.

But, for the sake of end users [who should never run in this mode] I propose:

1) remove this from the debug UI. Developers who want to do this can manipulate
   their prefs.js

2) rename the pref so that people who have accidentally set this pref without
   knowing what they were doing will 

(And by the way, we had a "topcrash" bug that was driven solely by users who 
had this pref set. The crash only occurred if this the pref to disable was 
set.)

I will post in n.p.m.xpfe before committing this. Does this seem reasonable?

Comment 1

[Matthias Versen [:Matti]]

we have this debug prefs for debugging. (and stupid users should not touch it)
We got already a few bugs about "debug xul boxes" and other things.
(i can try to get a bug list if you want)

what to do ?
a) remove all the debug settings from the GUI
b) activate this debug settings only with a special pref or build option (like
the broken new OS X browser)
c) leave it in the current state

Comment 2

[Serge Gautherie (:sgautherie)]

Reply to comment 2 (general discussion, not bug specific like comment 1):

As an end user,

*I would never dare to active any pref from the 'Debug > Events'
*I might want to try to deactivate 'Debug > ... Mozilla chrome ...' for example
*I do use/consider 'Debug > Networking > ...' as "regular" prefs: (Am I stupid
!? :-<)
 *XUL listing instead of HTML: looks much better to me (and does not looks like
a debug feature)
 *Enable Disk Cache: I don't have too much spare disk space
  (see bug 165301: having Disk Cache size = 0, I thought it could only save more
ressources by using this setting...)
 *Disable XUL Cache: I am not interested in this one, but the
"nglayout.debug.disable_xul_fastload" could have some interest (see bug 169777
for example, and the one about moving that file to the cache directory...)

*Lastly, only 'Debug > ... XBL ...' is marked "... under construction".

At first, I would not remove the UI, but make its "for developers only" purpose
clearer:

1) The 'Debug' panels could all bear a warning statement
2) The 'Debug' tree could (!?) be moved at the end of the list (_after_ "O. & D.
S.")
   Just like the Debug and QA menus which are added at the end of the main
toolbar for non major release builds.
3) If necessary, there could be a (hidden or UI) pref to activate its display
   Same for the two main menus if we go that way !?

Bottom line: I know it is labeled "D-e-b-u-g", but it simply looks too much like
all other prefs right now.
And no specific help is available to say otherwise either.

Also a reminder/question could be added to the bug report form(s) to take the
Debug prefs into account (either try without, or simply write which ones are
used)...

Comment 3

[John Morrison]

Yo, yo, yo. I filed this bug on one specific pref. I only want to hear about 
that specific pref.

(yes, 'debug xul boxes' is equally toxic and could be removed from the UI
too, but Matti file that as a separate bug).

Comment 4

[timeless]

renaming it and removing the ui is fine with me.

Comment 5

[John Morrison]

*** Bug 171375 has been marked as a duplicate of this bug. ***

Comment 6

[John Morrison]

Attachment: patch

I don't really know what I should rename it to. I just prepended '_' in this
version, but suggestions welcome. 

I'd like to actually get this done for 1.3b, because it seems that people
can't resist poking at things they know nothing about. (e.g., bug 169777,
comment 182 "I put it on 54 user profiles a couple weeks ago..." where 'it'
is this pref. Sigh).

If people still want to play with this, then there's not much we can do, but
at least this will stop advertising the pref in the UI.

Comment 7

[John Morrison]

Comment on attachment 113479 [details] [diff] [review]
patch

oh, and I emailed alecf about removing that onflush [which is not called by
anyone] to see if it was ok to remove that entirely, or if I should just change
the pref name there as well.

Comment 8

[jag (Peter Annema)]

Comment on attachment 113479 [details] [diff] [review]
patch

sr=jag.

Comment 9

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030210]

This patch got 'sr+' on 04;
But the bug is still on 10 (at least the UI) build, and marked 'New'.

Is that intended ?

Comment 10

[Boris Zbarsky [:bzbarsky]]

See the roadmap <http://mozilla.org/roadmap.html>.  We're in a freeze; patches
need a= to land.

Comment 11

[Serge Gautherie (:sgautherie)]

Reply to comment 10:

Did you actually mean to change Severity from minor to blocker ?
(Or did you rather want to set the flag "blocking 1.3: ?" !?)

I guess the question is now:
jrgm, do you want to set the flag "approval1.3: ?" on your patch ?
(Or are you waiting for something else to happen ?)

(I don't mean to hurry anyone: only I was feeling that the activity had
"stopped" suddenly ... then the v1.3 release could be missed :-()

Comment 12

[Boris Zbarsky [:bzbarsky]]

^&^%&%^ing accesskeys.

Comment 13

[John Morrison]

I'd like to land this for 1.3 and prevent end users from accidentally setting
this value and unintentionally experiencing poor performance and various UI
glitches (and on occasion crashes).

I posted to n.p.m.xpfe a couple of weeks ago, and received virtually no counter
argument against making this change. 

Comment 14

[Asa Dotzler [:asa]]

not gonna block for this. setting approval request flag for driver evaluation.

Comment 15

[John Morrison]

Sorry, I meant the approval flag (although I do _not_ want to finish 1.3
without this).

Comment 16

[Asa Dotzler [:asa]]

Comment on attachment 113479 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to 1.3.  John, can you write up an
item for the newsgroups and release notes that explains the change? Thanks.

Comment 17

[John Morrison]

checked in on 1.3 branch.

release note is...

The developer-only preference 'nglayout.debug.disable_xul_cache' has
been renamed to 'nglayout.debug.disable_xul_cache_ex' (with an '_ex'
at the end), and the UI in the debug panel has been
removed. Developers who which to set this preference can either add
back the UI in their own builds, or change it in 'about:config'. This
setting is strictly for developers, and is not suitable for any
end-users. [bug 190358]

where do I send this release note?

Comment 18

[Asa Dotzler [:asa]]

I'll add this to the release notes. 

Comment 19

[Matthias Versen [:Matti]]

*** Bug 196970 has been marked as a duplicate of this bug. ***

Comment 20

[Matthias Versen [:Matti]]

*** Bug 197367 has been marked as a duplicate of this bug. ***

Comment 21

[Daniel Fournier]

Renaming "nglayout.debug.disable_xul_cache" to
"nglayout.debug.disable_xul_cache_ex", as indicated by John in comment #17,
doesn't work in my 1.3 release.
XUL is always cached ;-(
Is this only for 1.4 branch ?

Comment 22

[Daniel Fournier]

Please forget comment #21: I was wrongly changing the pref in 1.2.1 release.
It WORKS in 1.3.
I apologize.

Comment 23

[Eric Murphy]

It would be nice to have this option in the prefs file by default. That way
people can turn it on/off in about:prefs.

This is still a *very* useful option for people developing Mozilla applications.
It should get a permanent name and be set in stone in the pref file.

Comment 24

[HJ]

We need a status update for this bug. Hey, and I don't get it. That debug pref
panel isn't even part of official netscape/mozilla releases, so why remove
something that isn't even available for end-users?

"The developer-only preference 'nglayout.debug.disable_xul_cache' has
been renamed to 'nglayout.debug.disable_xul_cache_ex' (with an '_ex'
at the end)"

I can't find 'nglayout.debug.disable_xul_cache_ex' but only
'nglayout.debug.disable_xul_cache' in the source, so what happend?

Comment 25

[Serge Gautherie (:sgautherie)]

Re comment 24: see comment 17 = (v1.3final only)

Comment 26

[Marc Abramowitz]

Unfortunately, there are a lot of docs that refer to the old name:

e.g.: http://kb.mozillazine.org/Dev_:_Tips_:_Disable_XUL_cache

How best to get the word out?

Comment 27

[Serge Gautherie (:sgautherie)]

(In reply to comment #26)
> Unfortunately, there are a lot of docs that refer to the old name:
> e.g.: http://kb.mozillazine.org/Dev_:_Tips_:_Disable_XUL_cache

Which old name are you refering to ?

That page reads
{{
nglayout.debug.disable_xul_cache

nglayout.debug.disable_xul_cache is a Mozilla preference useful for extension
developers. Basically when it is set to false (which is default), Mozilla caches
chrome XUL and JavaScript (and more) in a file named XUL.mfl or similarly.
Therefore, when making changes to your extension, you have to restart Mozilla in
order to get new version used. As it is very inconvenient, many extension
developers set this pref to true. 
}}
which seems right.

Comment 28

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 29

[Gregory Pappas [:gregp]]

This isn't an issue anymore