Closed Bug 84243 Opened 23 years ago Closed 14 years ago

full-page plugins don't show in sidebar

Categories

(SeaMonkey :: Sidebar, defect)

Product:
SeaMonkey
Component:
Sidebar
Platform:
x86
Other
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: mgalli, Unassigned)

References

(
URL
)

Details

(Keywords: regression, testcase)

Attachments

(1 file)

html code that add a flash url to the sidebar.
365 bytes, text/html
Details 
I will add the testcase (an attachment web page that includes a flash file to
the sidebar). Seems like some flash based apps in the sidebar are not starting.
Note that if you select the Tab, you can't see the flash. If you expand/collapse
the sidebar you will be able to see. If you select other tab and back to this
one... works too. 


This problem also occurs on the browser window, you cannot open a swf file by
writing filename.swf on the location bar, it seems that Netscape6 doesnt have
the MIME type for flash files so it always try to download the file instead of
playing it...
you can see the same problem by pointing your browser to a direct URL of one swf
file like http://www.mamata.com.br/index.swf
Summary: Problems with Flash (not sure if only flash) inside Sidebar. → Problems with Flash inside Sidebar.
Confirming.
Note: The chief problem here is that we can't get the plugin space to paint in
the sidebar window.  peterl, any of your fixes affect this?  it used to work in
0.6 (and thus Netscape 6.01).  Assigning to sidebar for now, till peterl or
someone determines this is a plugin bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla0.9.2, regression
Adding Sol. 

I will add another testcase. It may be related with this or not. But seems like
there is no <body onload> event fired for sidebar pages. 

Sorry,,... nothing related with onload event... 

nav triage team:

We think the layout team would be a better team to investigate this one.
Reassinging.
Assignee: matt → karnaze
Component: Sidebar → Layout
QA Contact: sujay → petersen
testcase no longer vlaid.
reassigning to core woner as it is not a table specific bug.
Assignee: karnaze → attinasi
Whiteboard: [NEED TESTCASE]
Peter any insight on this one?
Assignee: attinasi → peterl
Testcase is valid, simply replace the URL in the text box with a valid full-page
flash animation like:
http://www.mamata.com.br/index.swf

I think this could possibly be something to do with the uri loader or extension
handler which should direct that a plugin should be used to display the file.

A possible workaround is to embed your full-page plugin files in a host HTML
file if they are to be used in the sidebar.
URL: http://www.mamata.com.br/index.swf
Status: NEW → ASSIGNED
Component: Layout → Plug-ins
Keywords: mozilla1.0, testcase
Priority: -- → P1
Summary: Problems with Flash inside Sidebar. → full-page plugins don't show in sidebar
Whiteboard: [NEED TESTCASE]
I'm getting an:

JavaScript error:
 line 0: syntax error

Error loading URL javascript:void : 805303f5

on the testcase in the console before going into plugin code.
Target Milestone: --- → mozilla0.9.9
I'm not quite sure how it used to work, but I think this would be solved if
full-page plugins had a document. See bug 90256.

As a workaround, use the plugin with an EMBED or OBJECT tag.
Depends on: 90256
Priority: P1 → P2
Target Milestone: mozilla0.9.9 → mozilla1.0
nominating nsbeta1
Keywords: nsbeta1
Keywords: nsbeta1 → nsbeta1+
This may happen because full-page plugins in the sidebar doesn't cancel the
timer in:
http://lxr.mozilla.org/mozilla/source/xpfe/components/sidebar/resources/sidebarOverlay.js

Currently, PluginViewerImpl::LoadComplete is empty. I tried copying the
NS_PAGE_LOAD event dispatch from the document viewer, but no luck:

  nsCOMPtr<nsIPresContext> pc;
  nsCOMPtr<nsISupports> parent = mContainer;
  nsCOMPtr<nsIDocShell> docshell;
  while (parent && !pc) {
    nsCOMPtr<nsIInterfaceRequestor> requestor(do_QueryInterface(parent));
    if (requestor) {
      
      nsCOMPtr<nsIDocShellTreeItem> parentdoc;
      requestor->GetInterface(NS_GET_IID(nsIDocShell),
getter_AddRefs(docshell));            
      
      if (docshell) {
        docshell->GetPresContext(getter_AddRefs(pc));
        
        if (!pc) {
          nsCOMPtr<nsIDocShellTreeItem> item(do_QueryInterface(docshell));
          if (item)
            item->GetParent(getter_AddRefs(parentdoc));
        }
      }
      
      if (parentdoc)
        parent = do_QueryInterface(parentdoc);
      else 
        parent = nsnull;
    }
  }

  if (pc && docshell) {
    nsCOMPtr<nsIScriptGlobalObjectOwner> owner = do_QueryInterface(docshell);
    if (owner) {
      nsCOMPtr<nsIScriptGlobalObject> global;
      owner->GetScriptGlobalObject(getter_AddRefs(global));
      if (global) {

        nsEventStatus status = nsEventStatus_eIgnore;
        nsEvent event;
        event.eventStructType = NS_EVENT;
        event.message = NS_PAGE_LOAD;

        return global->HandleDOMEvent(pc, &event, nsnull, NS_EVENT_FLAG_INIT,
&status);
      }
    }
  }
No longer depends on: 90256
adding adt1 to status whiteboard as per discussion with beppe.
Whiteboard: [ADT1]
removing ADT1 and nsbeta1+ -- reassigning to sidebar folks, the plug-in works 
correctly in the content window, PeterL will help if you need info about the 
plug-in functions
Assignee: peterl → sgehani
Status: ASSIGNED → NEW
Component: Plug-ins → Sidebar
Keywords: nsbeta1+ → nsbeta1
QA Contact: petersen → sujay
Whiteboard: [ADT1]
Moving off radar while this is being considered for nsbeta1.  Do a lot of
sidebar developers use flash or other plugins?  Trying to guage the size of the
impacted audience which is going to be considered by ADT, no doubt.
Target Milestone: mozilla1.0 → mozilla1.2alpha
nsbeta1- per Nav triage team
Keywords: nsbeta1 → nsbeta1-
Product: Browser → Seamonkey
Assignee: samir_bugzilla → nobody
Priority: P2 → --
QA Contact: sujay → sidebar
Target Milestone: mozilla1.2alpha → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
WFM Linux trunk.
Resolution: EXPIRED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: