Closed Bug 448572 Opened 16 years ago Closed 16 years ago

Use smart getters in browser.js

Categories

(Firefox :: General, defect, P2)

defect

Tracking

()

RESOLVED FIXED
Firefox 3.1a2

People

(Reporter: asaf, Assigned: asaf)

References

Details

(Keywords: dev-doc-complete)

Attachments

(1 file, 1 obsolete file)

Attached patch patch (obsolete) — Splinter Review
No description provided.
Attachment #331770 - Flags: review?(mconnor)
Assignee: nobody → mano
Priority: -- → P2
Target Milestone: --- → Firefox 3.1a2
Status: NEW → ASSIGNED
OS: Mac OS X → All
Hardware: PC → All
Comment on attachment 331770 [details] [diff] [review] patch >diff --git a/browser/base/content/browser.js b/browser/base/content/browser.js >-function getNavToolbox() >-{ >- if (!gNavToolbox) >- gNavToolbox = document.getElementById("navigator-toolbox"); >- return gNavToolbox; I'm a bit nervous about removing this from an extension compat point of view, perhaps we should keep it in for now?
Attachment #331770 - Flags: review?(mconnor) → review+
Attached patch for checkinSplinter Review
Attachment #331770 - Attachment is obsolete: true
Changeset a2e861f6443c.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Will there be any issues of addons grabbing one of these globals too early, e.g., accessing gURLBar before prepareForStartup, and causing it to be stuck at null? Example code: while (gURLBar == null) waitForBrowserToGetReady();
Blocks: 448669
Is it possible that this is causing the TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/base/content/test/browser_bug409481.js | Timed out on tinderbox?
Looks like it was: there was a gNavigatorBundle assignment left over in web-panels.js. Pushed changeset f9423035dffe to fix that.
(In reply to comment #4) > Will there be any issues of addons grabbing one of these globals too early, > e.g., accessing gURLBar before prepareForStartup, and causing it to be stuck at > null? It might, but is that actually a common pattern? Does it actually work? I would expect your example to iloop, and I'd like to think that people aren't going to be doing the equivalent with timers.
I don't think it's common, and if we do break something.. the addon owner should make it less hacky! ;) (function showKeywords() { // Try to get the urlbar node if (gURLBar == null) return setTimeout(showKeywords, 100); // Change the search engine to include keywords gURLBar.setAttribute("autocompletesearch", "keyword " + gURLBar.getAttribute("autocompletesearch")); })();
(In reply to comment #8) > I don't think it's common, and if we do break something.. the addon owner > should make it less hacky! ;) > > (function showKeywords() { > // Try to get the urlbar node > if (gURLBar == null) > return setTimeout(showKeywords, 100); The gURLBar getter will be executed once only, so this wouldn't have the expected effect. I guess the getter should only delete itself if the element was found.
Depends on: 448862
Depends on: 448885
Version: unspecified → Trunk
Depends on: 448936
So if getBrowser() is deprecated, that should probably be documented on http://developer.mozilla.org/en/docs/Code_snippets:Tabbed_browser and it should be removed from all other pages on devmo. See also bug 448936.
Keywords: dev-doc-needed
Docs updated.
Blocks: 404110
Could this land on 1.9.0 to fix bug 404110?
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x?
Blocks: 448936
No longer depends on: 448936
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: