nsXULWindow::GetContentShellById() fails to return nsIWebShell pointer

RESOLVED FIXED in Future

Status

()

P3
normal
RESOLVED FIXED
19 years ago
18 years ago

People

(Reporter: moz_user, Assigned: jud)

Tracking

Trunk
Future
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
From Bugzilla Helper:
User-Agent: Mozilla/4.61 [en] (X11; U; Linux 2.2.12-20smp i686)
BuildID:    Milestone M14

nsXULWindow::GetContentShellById() fails to return nsIWebShell pointer when
element exists in XUL

Reproducible: Always
Steps to Reproduce:
1. Define the following element:
<html:iframe id="foo" type="content">
2. nsCOMPtr<nsIWebShell> content;
   rv = wsw->GetContentShellById("foo",getter_AddRefs(content));


Actual Results:  variable content is null

Expected Results:  expect variable content to reference <html:iframe>

I noticed that my nsWebShellWindow::GetContentShellById()
call no longer works in M14.  Tracking it down, it
appears nsHTMLFrameInnerFrame::CreateWebShell() in
nsFrameFrame.cpp saves the "type" attribute instead of
the "id" attribute when calling ContentShellAdded (a new
parameter added in M14).  That member function saves
the data to the "id" member of nsContentShellInfo object
(nsXULWindow.h).  When nsXULWindow::GetContentShellById()
is invoked, it compares aID with the saved "type".  This
appears to be a mismatch.

I temporarily changed the parameter I'm sending to
nsWebShellWindow::GetContentShellById() to use the
corresponding "type" attribute instead and the code
works fine now.

Upon further inspection, I see the code would work
if the "type" and "id" attributes of the <browser>
or <html:iframe> both start with the same text (as
in the case with navigator.xul).  However,
CreateWebShell() would have to be modified to save
off just the first 7 characters (it's already doing
this to check the type).  The function currently
saves the ENTIRE string...
becki@talkware.net - could you also have another look at this one? I have 
changed your Bugzilla permissions so, in future, bugs you submit get Confirmed 
immediately, and therefore should get more attention sooner. My apologies that 
these were left for so long.

Gerv

Comment 2

19 years ago
setting as New
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 3

19 years ago
Sorry I've been out of touch and unable to test the bug I reported.  An
untimely appendectomy took me out of commision for a month.  I'm
back to my PC so I'll check my bug against M16 and report back to you
as soon as I can.

--- becs
(Reporter)

Comment 4

19 years ago
I just finished looking at nsHTMLFrameInnerFrame::CreateDocShell() in
layout/html/document/src/nsFrameFrame.cpp for M16.  The call to
ContentShellAdded() has not changed since M15 so the problem still exists.  The
3rd parameter to nsXULWindow::ContentShellAdded() should be the element's ID and
not its type (which the variable "value" represents in CreateDocShell).  The
call should be changed to something like the following:

  nsIAtom* idAtom = NS_NewAtom("id");
  nsAutoString idValue;
  if (NS_SUCCEEDED(parentContent->GetAttribute(kNameSpaceID_None, 
    idAtom, idValue))) {
    parentTreeOwner->ContentShellAdded(docShellAsItem,
      value.EqualsIgnoreCase("content-primary") ? PR_TRUE : PR_FALSE,
      idValue.GetUnicode());
  }

(Assignee)

Updated

19 years ago
Target Milestone: --- → Future

Comment 6

19 years ago
Updating QA Contact
QA Contact: leger → jrgm
(Assignee)

Comment 7

18 years ago
marking fixed. the webshell ID retreival mechanism has been reworked. this
method doesn't exist anymore.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.