Closed Bug 24489 Opened 25 years ago Closed 25 years ago

Spurious "failed to get the xpfe.dragdrop.enable" console message

Categories

(Core :: XUL, defect, P3)

x86
Windows 95
defect

Tracking

()

VERIFIED INVALID

People

(Reporter: 3jrgm, Assigned: mikepinkerton)

References

()

Details

In the content: chrome/bookmarks/content/default/bookmarks.js chrome/navigator/content/default/navigator.js you have the following: var gDragDropEnabled = false; try { gDragDropEnabled = pref.GetBoolPref("xpfe.dragdrop.enable"); } catch (ex) { dump("failed to get the xpfe.dragdrop.enable pref, assuming it is off\n"); } which (by default) is dumping the message to the console (at least on win32) Perhaps, you want to provide 'user_pref("xpfe.dragdrop.enable", false);' to "prejs.js" by default to silence the spurious error. (Of course, you can't do this retroactively, but to head off the inevitable, this should go in M13, IMHO) (And, maybe, this is just a typo on 'enable' vs. 'enabled') Cheers, John
Status: NEW → ASSIGNED
Target Milestone: M20
is this really that important? it's a message to the console for pete's sake. m20.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
Nope. It's not important at all. It's obvious what's up if one takes a look. I only mentioned this because past experience tells me that well-meaning people _will_ file this a bug on this (more than once): "failed to get ..." suggests something went (badly) wrong. Marking INVALID (after all, it's only an interim thing). Sorry for the miscue.
shrug. ok ;)
Sorry for the spam, changing QA contact.
QA Contact: paulmac → jrgm
vrfy this code really doesn't exist.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.