Closed Bug 303058 Opened 19 years ago Closed 19 years ago

Missing plugin bar no longer appears

Categories

(Toolkit Graveyard :: Plugin Finder Service, defect)

x86
Windows 98
defect
Not set
major

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: me, Assigned: doronr)

Details

(Keywords: regression, verified1.8)

Attachments

(2 files)

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050801 Firefox/1.0+ Steps to Reproduce: 1. Visit a page that requests a plugin (see testcase). Expected Results: A yellow or white bar should appear at the top of the page with an "Install Missing Plugins" button. Actual Results: No bar appears, js console says: Error: window has no properties Source File: chrome://browser/content/browser.js Line: 5546 Which corresponds to: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/browser/base/content/browser.js&rev=1.466&mark=5845#5842 Regression Window: Works: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050705 Firefox/1.0+ Fails: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050706 Firefox/1.0+ Possibly caused/revealed by Bug 299520 or Bug 299450, not sure though.
Attached file Testcase for triggering PFS (deleted) —
Flags: blocking-aviary1.5?
CCing some people from checkin comments associated with the hidden bugs. Could either Bug 299520 or Bug 299450 have caused the following to throw "window has no properties": var window = aEvent.target.ownerDocument.__parent__; while (window.parent != window)
Yeah, this is a result of bug 299520. This code should really just be using defaultView instead of __parent__ to get at the window. Or we should make __parent__ work on XPCNativeWrapper somehow... Requesting blocking 1.8b4 in case we need to do the latter.
Flags: blocking1.8b4?
I just updated http://developer.mozilla.org/en/docs/XPCNativeWrapper#Limitations_of_XPCNativeWrapper to document this issue (item 8 in the list). Perhaps we should copy these props from Object.prototype to XPCNativeWrapper.prototype when we're setting our class up? Would that be safe? I'd assume it would...
This issue continues with the latest trunk: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050801 Firefox/1.0+ Change severity from major to trival, you can still install plugins, its just a cosmetic issue.
Flags: blocking1.9a1?
Flags: blocking-aviary2.0?
Flags: blocking-aviary1.0.7?
(In reply to comment #5) > Change severity from major to trival, you can still install plugins, its just a > cosmetic issue. It's not "just a cosmetic issue", it's pretty serious. There are pages that host "invisible" plugins, and without that bar you have no clue why nothing shows up.
Doron, any clues ?
Attached patch use defaultView as suggested (deleted) — Splinter Review
Assignee: nobody → doronr
Status: NEW → ASSIGNED
Attachment #191484 - Flags: review?(mconnor)
Not an issue on the 1.0 aviary branch. Not something we want to put off till 2.0 or Gecko 1.9. Leaving the 1.8b4 nomination, since I still think we might want to make core XPCNativeWrapper changes here.
Flags: blocking1.9a1?
Flags: blocking-aviary2.0?
Flags: blocking-aviary1.5?
Flags: blocking-aviary1.5+
Flags: blocking-aviary1.0.7?
Flags: blocking1.8b4? → blocking1.8b4+
Attachment #191484 - Flags: review?(mconnor)
Attachment #191484 - Flags: review+
Attachment #191484 - Flags: approval1.8b4+
checked into branch/trunk
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
Verified on trunk.
Status: RESOLVED → VERIFIED
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050815 Firefox/1.0+ ID:2005081512 verified on Branch
verified on Firefox 1.4 -mozilla1.8 branch- Win, Lin and Mac : 2005-09-07
Keywords: fixed1.8verified1.8
Product: Firefox → Toolkit
Product: Toolkit → Toolkit Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: