All users were logged out of Bugzilla on October 13th, 2018
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100928 Firefox/4.0b7pre Build Identifier: Mozilla/5.0 (X11; Linux x86_64; rv:2.0b7pre) Gecko/20100928 Firefox/4.0b7pre Unless I'm missing something, the patch that landed for Bug 574688 uses XULWindowBrowser.setStatusText, but doesn't actually define it. Early patch revisions defined it, but I didn't see any comment on why it was removed in later revisions. Also, it would also be nice if XULWindowBrowser.updateStatusField was added back to all the appropriate locations (with the function its self being a stub). That way, an extension wishing to implement a status widget would only need to implement updateStatusField, rather than updateStatusField and all of the setters. Reproducible: Always
Version: unspecified → Trunk
Asking for blocking, so that this doesn't get lost.
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Some overlap with (and asking for the opposite resolution approach) as bug 604093.
blocking2.0: ? → betaN+
Whiteboard: [addon bar]
Same issue as bug 604093, don't need two open bugs just because there are two potential solutions (I commented about the one suggested here in that bug).
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 604093
Reopening. This bug was about reimplementing XULBrowserWindow.setStatusText, which is different from what bug 604093 covered. IMHO setStatusText is important to have around for extensions to hook into. Yes, there are extensions that displayed messages in the old statusbar. So I think it's worthwhile to provide a central place for them to dump their messages, rather than have each implement their own status text widget. It would also provide a fixed API for extensions that wanted to implement a status text widget.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
There isn't a strong argument for us implementing setStatusText, see bug 604093 comment 12.
Status: REOPENED → RESOLVED
Last Resolved: 8 years ago → 8 years ago
Resolution: --- → WONTFIX
As far as I can see, bug 604093 comment 12 only commented on the DnD related code, which I am indifferent to. And I don't think having setStatusText would add any maintenance burden, given that setStatusText, setJSStatus, setJSDefaultStatus, and setDefaultStatus are all essentially identical functions. Also, when Bug 603777 lands, XULBrowserWindow.status will already be in use. Also, setStatusText doesn't need to have an actual implementation. An empty function with a descriptive comment would be sufficient. It should just be something discoverable by extension authors.
I don't understand why an an empty setStatusText stub would help extensions. Is the goal to provide a well-known entry point for third parties that want to display status text for people who have an extension installed that overrides our setStatusText? Very few people are going to install status bar text extensions, so I don't really see those third parties having much of an incentive to do that. If they really want to they can come up with an interface out of band (without it being maintained in core Firefox code).
Yes, the intention was to provide a well-known entry point for extensions. The situation I'd like to see avoided is extensions providing their own status text widget specific to just their extension. I'm actually really interested to see what kind of adoption rate Status-4-Evar will have once Firefox 4 is released. As it stands, I've already 5k - 6k active users (though without knowing the number of Firefox 4 beta users, that doesn't mean a whole lot), and I've already had some users ask how to edit their extensions to use it. Though, if it gets popular enough, a well-known entry point in Firefox won't really be needed. But it'd still be nice.
You need to log in before you can comment on or make changes to this bug.