104590 - Back in context menu not working correctly when in sidebar

Status: NEW

(SeaMonkey :: Sidebar, defect)

Description

[Jesse Houwing]

This can be tested with a sidebar with a link that doesn't open in _content, but
in _self (or no target at all).

Click such a link. Rightclick the panel and select "back" from the pulldown that
appears. It will issue a go back to the main window, not the sidebar.

tested using build: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4+)
Gecko/20011007.

Also tested with 0.9.4 and 0.9.5 both not working

Expected: back in sidebar should actually back the sidebar, not the main content
window.

Comment 1

[Samir Gehani]

Over to the new context menu owner: morse.  Bounce back to me if needed.

Comment 2

[Samir Gehani]

Confirming.

Comment 3

[Stephen P. Morse]

samir, can you please give the detailed steps that you used to confirm this.  
For example, what link did you use?

Comment 4

[Samir Gehani]

Steps to reproduce:
-------------------
(1) Add a sidebar panel that has links in it using the following steps:
  (a) Open the JavaScript console.
  (b) Type: window.sidebar.addPanel("test", "http://mozilla.org","");
  (c) Click OK in the add panel confirm dialog that pops up. 
Note: you can't do this in the URL bar by typing
javascript:window.sidebar.addPanel(...).  Make sure you do it from the
JavaScript console.
(2) In the main browser window visit a few pages so you accumulate session
history.  Let's say you visited netscape.com.
(3) Open the new sidebar panel entitled "test."
(4) Click on a link in the panel content (the mozilla.org homepage).  
(5) The panel iframe will now change to display the content of the link you
clicked on.
(6) Now right click in the "test" sidebar panel iframe area.
(7) elect "Back" in the context menu that pops up.

Actual results:
---------------
You will see that the main content area (where you visited netscape.com) will go
back, not the sidebar panel (where you visited mozilla.org).  This is not
expected behavior.  

Expected results:
-----------------
One would think that the context of this popup menu is the sidebar panel since
we are over it.  Hence, one would expect the sidebar panel content to go back a
page, not the main window content area.

Comment 5

[Samir Gehani]

BTW, when you add the panel, ignore the two exceptions that are reported in the
JavaScript console.  That's a separate bug.

Comment 6

[Stephen P. Morse]

Samir,

Step 1b in you instructions gives the following four error messages:

Error: [Exception... "'JavaScript component does not have a method named: 
"getHelperForLanguage"' when calling method: 
[nsIClassInfo::getHelperForLanguage]"  nsresult: "0x80570030 
(NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location: "JS frame :: <unknown 
filename> :: <TOP_LEVEL> :: line 0"  data: no]

Error: [Exception... "'JavaScript component does not have a method named: 
"getInterfaces"' when calling method: [nsIClassInfo::getInterfaces]"  nsresult: 
"0x80570030 (NS_ERROR_XPC_JSOBJECT_HAS_NO_FUNCTION_NAMED)"  location: "JS frame 
:: <unknown filename> :: <TOP_LEVEL> :: line 0"  data: no]

Error: [Exception... "Component returned failure code: 0x80004003 
(NS_ERROR_INVALID_POINTER) [nsIRDFContainer.Init]"  nsresult: "0x80004003 
(NS_ERROR_INVALID_POINTER)"  location: "JS frame :: 
file:///Y:/mozilla/dist/WIN32_D.OBJ/bin/components/nsSidebar.js :: anonymous :: 
line 122"  data: no]
Source File: 
file:///Y:/mozilla/dist/WIN32_D.OBJ/bin/components/nsSidebar.js
Line: 122

Error: uncaught exception: [Exception... "Component returned failure code: 
0x80004003 (NS_ERROR_INVALID_POINTER) [nsIRDFContainer.Init]"  nsresult: 
"0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame :: 
file:///Y:/mozilla/dist/WIN32_D.OBJ/bin/components/nsSidebar.js :: anonymous :: 
line 122"  data: no]

Comment 7

[Stephen P. Morse]

And I never get to step 1c (no dialog pops up)

Comment 8

[Stephen P. Morse]

Oops, ignore above comments.  I just tried it again and this time I got the 
pop-up dialog.

Comment 9

[Stephen P. Morse]

Problem is much worse than just BACK not working right when in sidebar

- menu contains frame entries even though sidebar panel has no frames
- view page source shows source for page in content area instead of sidebar
- view frame source shows the text that is in the sidebar
- back and forward apply to content area rather than sidebar

Updating summary from

   Back not working in sidebar

to

   Context menu not working correctly when in sidebar

Comment 10

[Stephen P. Morse]

After spending considerable time investigating this and getting nowhere, I have 
at least discovered the following useful pieces of information


1. The BrowserBack method (and other methods as well) in navigator.js is using a 
webNavigation that it got from the content area rather than the sidebar area.  
In essense it is doing 

   document.getElementById("content").webNavigation


2. The test for being in a frame is made in nsContextMenu.js and is

  if ( this.target.ownerDocument != window._content.document ) {
    this.inFrame = true;
  }

That test is coming up true when in the sidebar


3. And after all that I discovered that this is not a new bug after all.  It is 
a dup of bug 61304.  Will mark that bug a dup of this one rather than vice versa 
because, except for one comment from Blake, there is more info here.  I'll 
reproduce that comment here for convenience:

   "Eventually, context menu helper methods will be wrapped into <browser/>,
   and clients will have to build their own xul context menu (so sidebar will
   be able to construct its own menu with its own specific items)."

Comment 11

[Stephen P. Morse]

*** Bug 61304 has been marked as a duplicate of this bug. ***

Comment 12

[Stephen P. Morse]

[e-mail] just changed the title of this bug report by adding the 
parenthetic comment "thinks sidebar is a frame of the page in the content area".  
That's actually not true.  It's true that the context menu is getting confused 
and doing an erroneous frame test when you click in the sidebar.  But it doesn't 
follow that context menu thinks that we are in a frame of the page in the 
content area.

Removing parenthetical comment in title.

Comment 13

[Jesse Ruderman]

>But it doesn't follow that context menu thinks that we are in a frame of the 
>page in the content area.

If you take into account that both "back" and "view page source" act on the 
content area rather than the sidebar, I think it's reasonable to say that the 
context menu code thinks (or at least acts like) the sidebar is a frame of the 
content area.

Comment 14

[Stephen P. Morse]

Not going to make 9.6

Comment 15

[Samir Gehani]

Nominating for mozilla0.9.7.

Comment 16

[Boris Zbarsky [:bzbarsky]]

*** Bug 120941 has been marked as a duplicate of this bug. ***

Comment 17

[Jesse Houwing]

I'm using the following check to determine if my sidebar panel is loaded in a
window, or in a sidebar. It works perfectly.

if (!((typeof window.content == "object") && top == window.content)){

This could be added to the inframe/outframe check. And would fix this bug :)

Cool the first fix I actually thought up... I'd like to implement the fix, but I
don't have the tools at hand I'm afraid.

Comment 18

[Jesse Houwing]

Change this line:
if ( this.target.ownerDocument != window._content.document && ) {

in:
if ( this.target.ownerDocument != window._content.document && top ==
window._content) {

That should fix it.

Comment 19

[Jesse Houwing]

I'm unsure this will fix the back-issue this bug was started for, but it should
fix the incorrect context menu. But they will probably point to the main content
window, so there should be a check if it is inframe, or insidebar (or
outcontent) or something.

That check could be accomplished with the little line I entered before. But the
context menu actions need to take this additional boolean in consideration too...

(this is hypotethical, so please correct me if I'm wrong...)

Comment 20

[Henrik Gemal]

the latest javscript error is now:

Error: [Exception... "Component returned failure code: 0x80004003
(NS_ERROR_INVALID_POINTER) [nsIRDFService.GetDataSource]"  nsresult: "0x80004003
(NS_ERROR_INVALID_POINTER)"  location: "JS frame ::
chrome://communicator/content/sidebar/sidebarOverlay.js :: sidebar_overlay_init
:: line 774"  data: no]
Source File: chrome://communicator/content/sidebar/sidebarOverlay.js
Line: 774

Comment 21

[Stephen P. Morse]

reassigning to component owner

Comment 22

[u60234]

*** Bug 186840 has been marked as a duplicate of this bug. ***

Comment 23

[Vedran Miletic]

retargeting

Comment 24

[Daniel Wang]

*** Bug 171967 has been marked as a duplicate of this bug. ***

Comment 25

[Robert Kaiser]

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

Comment 26

[Jesse Houwing]

I tested it in Firefox 3.5.3 (Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.3) Gecko/20090824 Firefox/3.5.3 (.NET CLR 3.5.30729)) and it seems to be fixed there.

No longer using SeaMonkey so I cannot confirm this as fixed.

Comment 27

[therube]

I'm certainly not understanding this bug well enough.

Nevertheless there is a decidedly different set of results returned between SeaMonkey 2.1 vs. what is seen in FF4 - FF6.

Per Comment 26, it would be WFM - in FF.

But in SeaMonkey, I can confirm the comments in Comment 9, so IMO, this bug should be CONFIRMED (for SeaMonkey).

Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20110511 Firefox/4.0.1 SeaMonkey/2.1

Mozilla/5.0 (Windows NT 5.1; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110519 Firefox/6.0a1

Comment 28

[Phoenix]

Still here, correct steps to reproduce are in comment 4 with small change "JavaScript console"->"Error console"
Build identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20111017 Firefox/10.0a1 SeaMonkey/2.7a1

Comment 29

[Tony Mechelynck [:tonymec]]

Confirmed based on comment #28.

Mozilla/5.0 (X11; Linux x86_64; rv:10.0a1) Gecko/20111017 Firefox/10.0a1 SeaMonkey/2.7a1 ID:20111017003001

Trying to reproduce here, I get:
Warning: assignment to undeclared variable sidebarName
Source file: jar:file:///usr/local/seamonkey/omni.jar!/components/nsSidebar.js
Line: 181

at step 1c of comment #4, and no "test" tab in the sidebar. (xSidebar is installed but disabled. Console² is enabled.)

IOW I cannot reproduce it myself because masked by some other bug.