If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[Website Testing] Popup window will not load @ bankofamerica.com

VERIFIED FIXED in Chimera0.3


Camino Graveyard
16 years ago
15 years ago


(Reporter: Peter Scholtz, Assigned: Brian Ryner (not reading))


Mac OS X




(1 attachment)



16 years ago
Chimera Build: 0.30
Mac OS X: 10.1.5

Steps to Reproduce:
(1)Go to above URL
(2)Fill out the form, marking the "No" radio buttons for the second and third
(3)Any response for the first (any state) and last (Personal or Business)
questions should reproduce the bug
(4)Click the "Continue" button

What should appear is a popup window saying that your request cannot be
processed, which is what happens in Internet Explorer 5.1.  Instead, a blank,
untitled popup window appears, and doesn't load.

Hope I didn't forget anything important...

Comment 1

16 years ago
Found this bug again at a different location:

If you don't fill either field out, and click the "Add Bill Pay" button, another 
blank popup window appears.  Again, it's supposed to be telling you it 
can't process your request because you left out information, and it works 
properly in Explorer.

Comment 2

16 years ago
sounds like the popup not loading issue again
Assignee: saari → ccarlen

Comment 3

16 years ago
yes, indeed, related to http://bugzilla.mozilla.org/show_bug.cgi?id=149307 -
some popup windows do not render.

Adding this bug to chimera blockers list.
Blocks: 147975

Comment 4

15 years ago
Is this bug a duplicate of bug 149307?  That bug was just resolved today for
chimera so this may no longer be a bug (it should be tested with bits after 11am
i landed rpotts' fix and i get

JavaScript error: 

 line 0: uncaught exception: [Exception... "Component returned failure code:
0x80004003 (NS_ERROR_INVALID_POINTER) [nsIDOMNSHTMLDocument.write]"  nsresult:
"0x80004003 (NS_ERROR_INVALID_POINTER)"  location: "JS frame ::
:: writeWindow :: line 306"  data: no]

when the popup comes up
This is unlike bug 149307, which affected all embedding apps. I tried a PPEmbed
from yesterday ('cause it's possible to debug components in that env), and it
worked. (?)
This bit in the log (before the JS error) is interesting:

made a chrome window.
###!!! ASSERTION: null ptr: 'nsnull != aContainer', file nsHTMLContentSink.cpp,
line 2494
###!!! Break: at file nsHTMLContentSink.cpp, line 2494
###!!! ASSERTION: RemoveElementsAt(negative index): 'aIndex >= 0', file nsVoidArray.cpp,
line 573
###!!! Break: at file nsVoidArray.cpp, line 573

Different content structure between PPEmbed and Chimera because of different
form elements? 
taking this to free conrad to work on other things
Assignee: ccarlen → pinkerton
Target Milestone: --- → Chimera0.3

Comment 9

15 years ago
The problem seems to stem from us causing multiple documents to be created by
calling domWindow->GetDocument() at the time that CreateChromeWindow() is
called.  We do this so that we can get the current URL (why can't we just use

So, at any rate, asking for the document at this point, for this particular js
popup, causes an about:blank document to be created.  The script caches the
document attached to the domwindow as soon as it opens the window.  This
document then has its presshell removed when we unsuppress painting on the real
document, so when the script tries to write to that document... bad things
happen, because the webshell is gone.

Continuing to investigate...

Comment 10

15 years ago
Reassigning to myself, I have a patch.

The root of the problem is that Chimera is trying to load about:blank into the
window when it's opened, even if it was opened from script.  We need to avoid
doing this and let the docshell take care of setting up the synchronously loaded
about:blank document, or else js can end up with a reference to a dead document
once the document _we_ loaded comes in.
Assignee: pinkerton → bryner


15 years ago

Comment 11

15 years ago
Created attachment 89898 [details] [diff] [review]

This avoids loading any document into a new window if it was opened from
Comment on attachment 89898 [details] [diff] [review]

Attachment #89898 - Flags: review+

Comment 13

15 years ago
Comment on attachment 89898 [details] [diff] [review]

>+- (void)newTab:(BOOL)aAllowHomepage;

Are we using mozilla-style naming conventions in Obj-C code? I don't
particularly like them; I'd prefer none (allowHomepage) or one that reflects
the type of the parameter (inAllowHomePage). Minor.

>+    PRInt32 newTabPage = 0;
>+    if (aAllowHomepage) {
>+      nsCOMPtr<nsIPrefBranch> pref(do_GetService("@mozilla.org/preferences-service;1"));
>+      pref->GetIntPref("browser.tabs.startPage", &newTabPage);
>+    }
>     [newTab setLabel: (newTabPage ? @"Loading..." : @"Untitled")];

2 things.
1. I think we should assume that this pref can have 1 of 3 values, since this
is the
   way the pref is in mozilla:

    0: don't load anything
    1: load home page
    2: load last visited page (not impl. in chimera)

so I'd prefer here that you write

    [newTab setLabel: ((newTabPage == 1) ? @"Loading..." : @"Untitled")];

2.  @"Loading..." and @"Untitled" need to be localizable. Since you're here,
    you might as well do that  ;)

>-    [[newView getBrowserView] loadURI: (newTabPage ? [[CHPreferenceManager sharedInstance] homePage: NO] : @"about:blank") flags:NSLoadFlagsNone];
>+    if (aAllowHomepage)
>+      [[newView getBrowserView] loadURI: (newTabPage ? [[CHPreferenceManager sharedInstance] homePage: NO] : @"about:blank") flags:NSLoadFlagsNone];

Use (newTabPage == 1) here too.

Fix those, and sr=sfraser
Attachment #89898 - Flags: superreview+

Comment 14

15 years ago
Checked in.
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 15

15 years ago
Verified.  7/8 build on OS 10.1.5.


15 years ago
No longer blocks: 147975
You need to log in before you can comment on or make changes to this bug.