Closed Bug 417740 Opened 17 years ago Closed 15 years ago

Google Calendar "print" displays a blank window and logs "uncaught exception: Permission denied to get property Window.DOM Constructor.prototype" error

Categories

(Camino Graveyard :: Page Layout, defect)

Product:
Camino Graveyard
Component:
Page Layout
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino2.1

People

(Reporter: philbert433-bugzilla, Assigned: stuart.morgan+bugzilla)

References

Details

(Keywords: regression, Whiteboard: [camino-2.0.5])

Attachments

(1 file)

fix
9.27 KB, patch
mikepinkerton
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.12) Gecko/20080206 Camino/1.5.5 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en; rv:1.8.1.12) Gecko/20080206 Camino/1.5.5 Prior to download of 1.5.5 I was able to print a Google Calendar with no problems. After the download it no longer works. Upon clicking the Print hotbutton on the Calendar, a new window pops up (which is how it worked before the change). Previously, the new window contained a printer ready version of the calendar. After the download , however, the window is blank, and nothing happens. Reproducible: Always Steps to Reproduce: 1.Open Google calendar 2.Select print calendar Actual Results: Blank window pops up. Expected Results: Print-ready calendar.
Odd; I can reproduce this with a recentish trunk, with CC showing JavaScript Error: "uncaught exception: Permission denied to get property Window.document", but Firefox 2.0.0.12 and today's Minefield are both fine.
We should run through the 1.5 nightlies and try to get a regression range.
Another missing xpt?
Flags: camino1.6?
Flags: camino1.5.6?
Philbert: what version of Camino did you upgrade from (i.e., what were you using prior to 1.5.5)? cl
In Response to Chris Lawson's inquiry -- I had been using 1.5.4 without any problems.
I'm not sure that I'm doing this correctly, but I've gone back with 1.5.x releases as far as 1.5.3 (and a 1_8 branch nightly from early September), and I never get anything other than a blank window. These are the steps I used, with a fresh profile: 1) Go to http://calendar.google.com (log in if necessary) 2) Click the "Print" link above the displayed calendar 3) Observe blank window Philbert: is that what you were doing?
In response to Smokey -- that's about it -- although it was working for me before the latest download -- BTW, it works OK in Firefox and Safari (opens the print preview window)
(In reply to comment #1) > JavaScript Error: "uncaught exception: Permission denied to get property > Window.document" On 1_8 branch this reads: JavaScript Error: "uncaught exception: Permission denied to get property Window.DOM Constructor.prototype"
I can get this to work if I mess around with the single-window mode prefs; enabling SWM *and* flipping the hidden pref to force all windows to be redirected (setting browser.link.open_newwindow.restriction to 0). But the fact that that's the only way I can ever get it to work doesn't help find a regression range.
(In reply to comment #6) > I'm not sure that I'm doing this correctly, but I've gone back with 1.5.x > releases as far as 1.5.3 (and a 1_8 branch nightly from early September), and I > never get anything other than a blank window. It is very possible that Google Calendar changed something since/coinciding with the release of 1.5.5, something that doesn't go well for Camino. (spoofing as Firefox 2 or 3b3 doesn't help, btw.)
Philbert, if you go back to Camino 1.5.4, does printing still work for you?
In response to Smokey -- I haven't tried. How do I go back to 1.5.4? I need to save my Bookmarks and KeyChains (&cookies?)
Philbert, you can follow these steps. Camino 1.5.4 will use all of the same bookmarks/cookies/passwords as 1.5.5 is using now. 1. Download 1.5.4 from http://caminobrowser.org/download/releases/#past 2. When the download is done, quit Camino 1.5.5 3. Double-click on the disk image file (Camino-1.5.4.dmg) that you've just downloaded to open it 4. Double-click on the Camino icon in the disk image window (normally you wouldn't run Camino like this, but it saves time when testing) 5. Test Google Calendar 6. Quit Camino 1.5.5 7. Eject the disk image (select the white disk with the blue logo on your Desktop and hit Cmd-E) 8. You can now throw away the Camino-1.5.4.dmg file you downloaded
Er, step 6 should read "Quit Camino 1.5.4" (the version you're testing).
In Response to Smokey: I tried 1.5.4 (and 1.5.3 while I was at it) and it didn't work, i.e. opens blank window with untitled in the title bar. No idea of why it worked before with 1.5.4 (and definitely with 1.5.3) but doesn't work now --
It sounds like what philippe theorized--Google changed something that caused this to break for us, approximately at the same time as 1.5.5 was released--is the case here. We've all seen the bug now, and the STR are clear, so confirming. Do we know anyone on the Calendar team that might be able to help from that end (even just tell us what changed, to see if that's a pointer towards the source of the problem)? (In reply to comment #3) > Another missing xpt? I don't seem to have noted this here, but earlier I installed all the xpts we don't ship and it didn't make any difference in the behavior.
Status: UNCONFIRMED → NEW
Component: Printing → Page Layout
Ever confirmed: true
QA Contact: printing → page.layout
Summary: Google Calendar fails to print after download of Camino 1.5.5 → Google Calendar "print" displays a blank window and logs "uncaught exception: Permission denied to get property" error
(Yay for stripping anything after the return when pasting :p )
Summary: Google Calendar "print" displays a blank window and logs "uncaught exception: Permission denied to get property" error → Google Calendar "print" displays a blank window and logs "uncaught exception: Permission denied to get property Window.DOM Constructor.prototype" error
Since this isn't a regression, minusing for 1.6 (although we'd certainly consider taking any patch that shows up). I'll try to trace this down to a failure point in the debugger when I get a chance.
Severity: major → normal
Flags: camino1.6? → camino1.6-
I've had the same problem, and going back to an earlier version (1.5.4, i think) DID work for me. The current version (1.6b4) also does the same thing--displays the blank window. As someone mentioned earlier, Firefox handles it fine.
Camino 1.5.6 is not happening.
Flags: camino1.5.6? → camino1.5.6-
Depends on: 434522
Do we do anything special (with regard to Gecko) when we make "chrome windows," or is that just how we indicate someone's requested a popup window that shouldn't become a full-fledged browser window? This is how this bug outputs console spew now: > Made a chrome window. > ^G###!!! ASSERTION: Why is there a document channel?: '!chan', file /Users/smokey/Camino/dev/trunk/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp, line 1767 > JavaScript error: http://www.google.com/calendar/static/82b6bc440914c01297b99b4bca641a5dcalendarjs_doozercompiled__en.js, line 141: Permission denied to get property Window.document (None of those appear in an [admittedly ancient] fx3 debug build.)
On 1.9.1, the error becomes slightly more informative: Made a chrome window. ^G###!!! ASSERTION: Why is there a document channel?: '!chan', file /Users/smokey/Camino/dev/191branch/mozilla-1-9-1/embedding/components/windowwatcher/src/nsWindowWatcher.cpp, line 1822 JavaScript error: http://www.google.com/calendar/static/052bdefe1ad48d4500d469a00299631ecalendarjs_doozercompiled__en.js, line 155: Permission denied for <http://www.google.com> to get property Window.document from <moz-safe-about:blank>.
I just went back and did some more checking, and this works as far back as 1.5 now, and as far forward as 1.6.11 (as long as you don't have the hidden "replace" SWM pref set). (Google will complain that you're an unsupported browser, but Print works regardless; spoofing as 2.0 gets rid of the complaining, and Print still works.) So it sounds like that at some point Google fixed a bug on their end (like comment 10 and 16 speculated), but then we got stuck with another bug, a real regression, which is what comment 21+ cover. This is better news, which means we can track down a regression range in trunk builds and hopefully figure out what Gecko change broke us and perhaps how to fix it. It's broken in 2.0a1 (2008-10-18 18:00), so somewhere between then and the 1.8 branch point (2005-08-12), this broke. In fact, 2006-05-09 03:00 trunk works, so that's only about 2 years to check. I tend to suspect something around June 2006, which is when bug 337746 and bug 342108 landed, and they were involved with the "moz-safe-about" protocol that gets references in the 1.9.x>0 branch errors. regression-range-wanted.
Keywords: regression, regressionwindow-wanted
I get the following: works: Version 2007061001 (2.0a1pre) fails: Version 2007061022 (2.0a1pre) http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-06-10+00%3A00%3A00&maxdate=2007-06-10+22%3A00%3A00&cvsroot=%2Fcvsroot In that list, bug 379315 is certainly not a candidate :-) Relevant possibly (probably ?) is bug 380786. A couple of JS bugs: bug 372666, bug 380970
I don't think it's bug 380786 (xpfe/ cleanup) based on the changes there (particularly as the bug persists in Camino-with-toolkit), though that's certainly screwed us before in bizarre ways. Bug 380970 is effectively just changing the URI to XPCOMUtils.jsm (which we didn't package at that point, anyway, but which we do now, and this bug still exists) Bug 372666 I can't say anything one way or the other about. I also came up bug 382383. But, you know, my guess in comment 25 was wrong, so who's to say any of this analysis is any better :P I backed out bug 382383 manually and it didn't seem to change things; bug 372666 won't back out cleanly, and there's too much going on there for me to feel comfortable backing it out manually. It's unclear if it was possible to build on 10.5 at that time (to step through the checkins to discover the guilty one).
Keywords: regressionwindow-wanted
(In reply to comment #27) > It's unclear if it was possible to build on 10.5 at that time (to step through > the checkins to discover the guilty one). Luckily (and amazingly!), with only two changes--fixing the xcodebuild_version check in configure, and disabling IBPalette in our Makefile--it is indeed possible to build mid-2007 Gecko/Camino trunk on 10.5. :-) > Bug 372666 I can't say anything one way or the other about. Now I can say that it triggered this regression. I built by date and checkins through 13:58 work, checkins through 14:00 fail, backing dom/src/jsurl/nsJSProtocolHandler.cpp up to 1.143 works, moving dom/src/jsurl/nsJSProtocolHandler.cpp forward to 1.144 fails. Boris, do you have any ideas here? This bug is a bit messy (there was a Google bug on branch that confused us for a long time), so the executive summary is: 1) Log into Google Calendar with a Camino with Gecko 1.9.x 2) Click Calender's print link/icon AR: Blank, sized window opens (and console warns in a debug build) ER: Blank, sized window opens, and then shows a calendar print preview and some options The debug console logging on current 1.9.2 is: [1]Made a chrome window. [2]^G###!!! ASSERTION: Why is there a document channel?: '!chan', file /Users/smokey/Camino/dev/192branch/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp, line 1812 [3]JavaScript error: http://www.google.com/calendar/static/18dec598971f9360c9bfe72e6c0e414ecalendarjs_doozercompiled__en.js, line 172: Permission denied for <http://www.google.com> to get property Window.document from <moz-safe-about:blank>. [1] http://hg.mozilla.org/camino/annotate/86e64794f790/src/embedding/CHBrowserListener.mm#l191 [2] http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/b2da18a3f256/embedding/components/windowwatcher/src/nsWindowWatcher.cpp#l1812 [3]
Blocks: 372666
> Boris, do you have any ideas here? Which part of the patch causes the problems? The EnsureInnerWindow() call, or the inner window comparison-and-bail-out? The assert [2] there seems highly relevant. Does it happen without the patch for bug 372666?
It's the compare-and-bail that's killing it. They don't match, but if I skip the error return the window content loads perfectly.
(In reply to comment #29) > The assert [2] there seems highly relevant. Does it happen without the patch > for bug 372666? It happens even without/before the patch for bug 372666.
OK. So the assert there is the real issue. The rest is a corrolary: the javascript: load starts against one window, but by the time the JS is supposed to run it's been replaced by a different window. This is normally a security bug, and the safe thing from a security perspective is to not run the JS. That's what bug 372666 was about. So you really need to fix whatever is triggering that assertion. Note the comments in that DEBUG block around the assert; you really don't want to be failing this assertion! Camino implements nsIWindowProvider, right? Does this window provider make sure that the window it returns isn't loading anything before returning it?
We're not hitting our re-use code path in ProvideWindow; we're just giving back null. Maybe we're doing something wrong in CreateChromeWindow (or later), causing an explicit about:blank load to happen when it shouldn't?
Possible... At the assert point, what's loading in the window? That is, what URI is |chan| for? Can you track when the nsDocShell::InternalLoad call happen between when the window watcher calls into CreateChromeWindow and when it calls ReadyOpenedDocShellItem?
I just found it in our code; the way we do the setup in CreateChromeWindow causes us to load about:blank in the window instead of leaving it empty, and if I prevent that it loads correctly. I need to wire up some extra params so that we treat the "create a new parented window" case as having a pending URI. As always, thanks for steering us in the right direction!
[01:47am] smorgan: Oh, I missed that we are supposed to be suppressing it already [01:47am] sauron: ? [01:47am] smorgan: The call to disableLoadPage [01:47am] smorgan: I didn't notice that we were theoretically already preventing this from happening [01:48am] smorgan: It just doesn't do the right thing [01:48am] smorgan: That will make fixing it even easier; no new params necessary We'll obviously want to take this fix for 2.0.5, too, once Stuart gets it coded.
Assignee: nobody → stuart.morgan+bugzilla
Flags: camino2.0.5?
Target Milestone: --- → Camino2.1
It looks like maybe smfr broke this in bug 161856 when fixing (drag-and-)drop handling for empty tabs :P http://hg.mozilla.org/camino/rev/546e35705343 is where we picked up the ternaries, at least.
> As always, thanks for steering us in the right direction! You're quite welcome!
Yep, smfr broke it; that part of his change was wrong. The real problem was that at the time he made that change, the implementation of the newTab: IB action was wrong--probably because of the confusion around the parameter to createNewTab being allowHomepage, when what it really controlled was doing any kind of initial page load (home page or about:blank, depending on pref)--so it followed the same path as a script-created window. That has since been fixed.
Attached patch fix — — Splinter Review
This looks like more of a change than it is, since I did some cleanup nearby. The substantive changes: - createNewTab: is back to taking just a BOOL, since there are really only two states (but it's a better-named BOOL now). - mShouldLoadHomepage has been given a better name (which inverts its meaning). Cleanup is to remove a bunch of NO/0/nil initializations (since mShouldLoadHomepage is inverting the new variable would be initialized to NO, which is why it is removed), fix the indentation in createNewTab:, and make createNewTab: private since it's not (and shouldn't be) called externally.
Attachment #472617 - Flags: superreview?(mikepinkerton)
The fix is simple, so we should land it for 2.0.5 as well.
Flags: camino2.0.5? → camino2.0.5+
Comment on attachment 472617 [details] [diff] [review] fix Thanks for tracking this down! sr=pink
Attachment #472617 - Flags: superreview?(mikepinkerton) → superreview+
http://hg.mozilla.org/camino/rev/a7937483b5c5 Smokey, can you do branch?
OS: Mac OS X → Windows 7
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
OS: Windows 7 → Mac OS X
Hardware: PowerPC → All
(In reply to comment #43) > http://hg.mozilla.org/camino/rev/a7937483b5c5 > > Smokey, can you do branch? Only if your browser stops changing bugs to Win7 ;) Landed on CAMINO_2_0_BRANCH for 2.0.5 :D
Whiteboard: [camino-2.0.5]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: