Plugin is destroyed immediatey if SRC="file.name" doesn't exist

VERIFIED FIXED

Status

()

Core
Plug-ins
P3
minor
VERIFIED FIXED
17 years ago
16 years ago

People

(Reporter: av (gone), Assigned: av (gone))

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: patch, review needed)

Attachments

(1 attachment)

(Assignee)

Description

17 years ago
This is a testcase:

<HTML><BODY>
<embed src="bogus.wav" type="audio/wav" width=300 height=160>
</BODY></HTML>

Have it saved into a local file, have a qtplugin.dll (or any other wav capable 
pluign) in the Pluigns folder, don't have bogus.wav, and open the testcase via 
file:// protocol. 

Expected: plugin loads and stay, not playing as there is nothing to play.
Actual: plugin briefly appears and then gets destroyed.

Note that this doesn't happen if the test case is served via http. But this is a 
possible bug in networking, see bug 76590.
(Assignee)

Comment 1

17 years ago
The following change in nsPluginHostImpl::InstantiateEmbededPlugin seems to 
help (close to the bottom of the function body):

  // don't make an initial steam if it's a java applet
  if(!aMimeType || 
     (PL_strcasecmp(aMimeType, "application/x-java-vm") != 0 && 
      PL_strcasecmp(aMimeType, "application/x-java-applet") != 0))
-   rv = NewEmbededPluginStream(aURL, nsnull, instance);
+   NewEmbededPluginStream(aURL, nsnull, instance);

So we shouldn't care about the success of getting the stream and thus don't 
trigger CantRenderReplaceElement which causes the object frame being destroyed.

Peter, there is a couple of more calls to NewEmbeddedPluginStream but I am not 
sure if should do the same there.
Severity: normal → minor
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla1.0
(Assignee)

Comment 2

17 years ago
*** Bug 73060 has been marked as a duplicate of this bug. ***

Comment 3

17 years ago
Created attachment 31467 [details] [diff] [review]
fixing a few more times where NewEmbededPluginStream is called

Comment 4

17 years ago
How important is this? 
(Assignee)

Comment 5

17 years ago
If 76590 is fixed this bug's importance will be higher, but anyway correct HTML 
code will not trigger it. Definitely not a stopper.

Comment 6

17 years ago
Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)
Target Milestone: mozilla1.0 → mozilla1.0.1
(Assignee)

Updated

17 years ago
Whiteboard: patch, review needed

Comment 7

17 years ago
nominating for mozilla1.0 and clearing milestone for re-triage....

Andrei, do you recall want needs to be done here? Do you know if the patch is
till good? Who should review it?
Keywords: mozilla1.0, patch, review
Target Milestone: mozilla1.0.1 → ---
(Assignee)

Comment 8

17 years ago
I don't see it happening any more. At least with QT on Windows. Must have been 
fixed as a side effect of something else. Marking.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Keywords: patch, review
Resolution: --- → FIXED

Comment 9

16 years ago
v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.