Closed Bug 309721 Opened 19 years ago Closed 18 years ago

Broken "window.screen" within HTML page inserted via <object type="text/html"> in XHTML pages sent as application/xhtml+xml

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: jon, Unassigned)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(4 files, 1 obsolete file)

debug build output
4.32 KB, text/plain
Details
stack + member vars
11.31 KB, text/plain;charset=UTF-8
Details
stack for doCreateDocShell
8.81 KB, text/plain
Details
Updated to tip; only partial fix still; checked in.
5.48 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050922 SeaMonkey/1.1a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050922 SeaMonkey/1.1a

The above URL works in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050921
Firefox/1.6a1 ID:2005092100

... yet is broken from:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050921
Firefox/1.6a1 ID:2005092116

When the page is first loaded with nothing cached, the "Google Adsense" loads
correctly (shows after the line "Brought to you by /usr/games/fortune..."),
where the Adsense code physically exists on a simple HTML page, where in turn it
is "inserted" into an XHTML page served as application/xhtml+xml via <object
type="text/html">.

However, when clicking the link "The amazing Fortune Cow says…" to reload the
page, the Adsense document is not shown ("partially" refreshed, as the XHTML is
dynamic PHP, the HTML page is static, and thusly cached). The Adsense will only
correctly be shown again by forcing a refresh of the same page either by
pressing <F5> or by clearing the browser cache before attempting to click the
link (both dynamic and static content get reloaded).

Looking at DOMi, the IFRAME element in the Google Adsense is created via
javascript on "clean" load, yet isn't when just "partially" refreshed.

The javascript console throws up the following error on "partially" refreshed
attempts:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMScreen.height]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
http://pagead2.googlesyndication.com/pagead/show_ads.js :: google_get_user_data
:: line 55"  data: no]

onTabLoad: notab tabbrowser

Reproducible: Always

Steps to Reproduce:
1. Clear browser cache (in the unlikely event you may have visited the site)
2. Go to http://lambcutlet.org/fortune-cow/
3. Google Adsense banner should show just after "Brought to you by..."
4. Click "The amazing Fortune Cow..." link to reload dynamic content of the page

Actual Results:  
Google Adsense banner does not show, and will only show once a full refresh of
the page is done.

Expected Results:  
Behave as per build:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050921
Firefox/1.6a1 ID:2005092100

... where the Google Adsense is loaded every time, regardless of how the page
was "refreshed".

http://jessey.net/ is another website which is using XHTML served as
application/xhtml+xml and has Google Adsense inserted via <object
type="text/html">. Curiously this does work for him, and the only "difference"
is that the HTML page which contains the Adsense code is a PHP page, and hence
dynamically generated each time, as it is not cached.
Keywords: regression
Works for me with:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050922
Firefox/1.6a1
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050922
Firefox/1.6a1 ID:2005092222

Yeah, I get the same error after clicking the link 7 times or so.
Also suddenly this: http://img378.imageshack.us/img378/5442/cow3wi.png 
(In reply to comment #3)
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050922
> Firefox/1.6a1 ID:2005092222
> 
> Yeah, I get the same error after clicking the link 7 times or so.

Curious, wonder why it requires more clicks for you?

> Also suddenly this: http://img378.imageshack.us/img378/5442/cow3wi.png 

That's just my sloppy PHP coding (and unrelated to this bug report)! :D
No missing ad in 1.9a1_2005092110. 
So now the regression date is between 2005092110 - 2005092116.
Had to click really a lot of times. :) 
I can't reproduce this... are any extensions (eg adblock) involved here?
(In reply to comment #5)
> No missing ad in 1.9a1_2005092110. 
> So now the regression date is between 2005092110 - 2005092116.
> Had to click really a lot of times. :) 

"Good" I guess, as that would still be consistent with a regression bug with the
fixing of bug 1156

(In reply to comment #6)
> I can't reproduce this... are any extensions (eg adblock) involved here?

No adblock, but I do have:

* Nightly Tester Tool
* Colorzilla
* FLST
* EditCSS
* Google Toolbar
* Session Saver
Does this bug still happen if you disable all of those?

If so, and if you can create a minimal testcase (still loading google's stuff is
fine), that would be nice.  If not, which extension causes the issue?
(In reply to comment #8)
> Does this bug still happen if you disable all of those?

Yes it does, though the javascript console only shows on error:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMScreen.height]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
http://pagead2.googlesyndication.com/pagead/show_ads.js :: google_get_user_data
:: line 55"  data: no]

... the one after in the first comment of the bug report must be related to the
FLST extension.

> 
> If so, and if you can create a minimal testcase (still loading google's stuff is
> fine), that would be nice.  If not, which extension causes the issue?

I created a PHP generated XHTML page and still see the issue, curiously though,
I did need to load it a few times as per what others have mentioned before the
non-display and above console error occured.

After a bit of Googling, found a couple more XHTML webpages with adsense loaded
the same way, exhibiting the same effect:

http://www.workingwith.me.uk/

and...

http://www.neothermic.com/

I think I was seeing the "effect" sooner with normal browsing as I generally
have a boat load of tabs (30+) open at any one time?
Oh, so this isn't reproducible the first time you reload the page (per comment
0, it sounded like that was the way to reproduce)?

Again, as small a testcase as possible that shows the problem would be much
appreciated....
(In reply to comment #10)
> Oh, so this isn't reproducible the first time you reload the page (per comment
> 0, it sounded like that was the way to reproduce)?
> 
> Again, as small a testcase as possible that shows the problem would be much
> appreciated....

When I was trying out various things, having less open tabs at the same time
seemed to require whatever problem page to be loaded more times before the
javascript exception came up (which halts the Google ad being shown).

I've hosted a dynamic base page here:

http://lambcutlet.org/files/test-cases/adsense-object.php

... for those that care what (little) PHP there is, see here:

http://lambcutlet.org/files/test-cases/adsense-object.phps

so I should load that page, hit reload a couple of times, and eventually see the
ads disappear?
(In reply to comment #12)
> so I should load that page, hit reload a couple of times, and eventually see the
> ads disappear?

Click the "self referencing" link: adsense-object.php

Hitting reload doesn't (so it seems) cause the bug to appear as the HTML object
is reloaded as well.
I've not managed to reproduce this...
(In reply to comment #14)
> I've not managed to reproduce this...

I'm still affected by this quirk on a clean build of Windows XP, using Firefox:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051008
Firefox/1.6a1 ID:2005100821

Still the same error...

---
Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMScreen.height]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
http://pagead2.googlesyndication.com/pagead/show_ads.js :: google_get_user_data
:: line 56"  data: no]
---
Can anyone on windows reproduce this with a debug build?
can't reproduce in seamonkey/windows :(

OK, does this happen in a new profile as well?
with a firefox nightly zip build on windows I can't reproduce this either :(
(clean profile, no extensions)
(In reply to comment #16)
> Can anyone on windows reproduce this with a debug build?

I can try with a debug build if I knew where it such builds exist for Win32?

Building from source ( http://gemal.dk/mozilla/build.html ) is rather out of the
question for me due to slow Internet connection and what not.
A debug build would be on the order of a gig or more in size, so building it is
about the only way to get one...
(In reply to comment #20)
> A debug build would be on the order of a gig or more in size, so building it is
> about the only way to get one...

That rules that idea (downloading it) out then. :)
For whatever reason, I can't reproduce this bug consistantly anymore on the
initial reported page, with Firefox build:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051012
Firefox/1.6a1 ID:2005101221

However, I do still see the same non-advert loading and script error with:

http://www.neothermic.com/ (Google ad on the left bar)

*beware, slow page with lots of (work safe) thumbnail images...
http://lambcutlet.org/blog/2005/09/29/2005-tai-hang-fire-dragon-dance-photogasm/
(Google ad just before the comments at the bottom)

Same old error...

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMScreen.height]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
http://pagead2.googlesyndication.com/pagead/show_ads.js :: google_get_user_data
:: line 56"  data: no]
so does this work in a new profile or not?
hah!
Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMScreen.height]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
http://pagead2.googlesyndication.com/pagead/show_ads.js :: google_get_user_data
:: line 56"  data: no]

now if only that had been a debug build... (this was on neothermic, with a
firefox nightly, new profile)
(on winxp)

I'll make a firefox debug build, I guess...
(In reply to comment #24)
> hah!
> Error: uncaught exception: [Exception... "Component returned failure code:
> 0x80004005 (NS_ERROR_FAILURE) [nsIDOMScreen.height]"  nsresult: "0x80004005
> (NS_ERROR_FAILURE)"  location: "JS frame ::
> http://pagead2.googlesyndication.com/pagead/show_ads.js :: google_get_user_data
> :: line 56"  data: no]
> 
> now if only that had been a debug build... (this was on neothermic, with a
> firefox nightly, new profile)

Phew... thought I was going mad! Look forward to seeing what's the cause of this
quirk.
Attached file debug build output — 
hm, not sure the debug output is much help (btw, this is really hard to
reproduce, happens very rarely)

I should probably set some breakpoints next...
Attached file stack + member vars — 
nsScreen members:
- mDocShell is not null
- mDocShell->mContentViewer is not null either
- The content viewer's device context is null, though
  So are its pres shell and its pres context.
- the docshell's bounds are all zeroes
doCreateDocShell is only called after the script runs and accesses
window.height
Attached patch Patch to try (obsolete) — — Splinter Review 
Per debugging with biesi, we think this should work.  Biesi, does this fix
things for you?
unfortunately this doesn't help :( the prescontext is still null, and therefore
I still get the assertion.
there was no same type parent of the docshell in
nsDocument::FlushPendingNotifications... so doc->FlushPendingNotifications
wasn't called. however, a presshell was available, and its
FlushPendingNotifications was called.

It looks like the docshell's parent has an item type of 0 while the child
docshell has a type of 1.

I have no idea if that is relevant... (that parent docshell is, I suppose, the
browser docshell.)
> there was no same type parent of the docshell in
> nsDocument::FlushPendingNotifications... so doc->FlushPendingNotifications
> wasn't called. however, a presshell was available, and its
> FlushPendingNotifications was called.

Right.  That would be expected.  This FlushPendingNotifications on the presshell
didn't construct the nsSubdocumentFrame?

> It looks like the docshell's parent has an item type of 0 while the child
> docshell has a type of 1.

Right.  The parent is the browser chrome, while the child is our content tab...

At what point _was_ the subdocument frame constructed?
it was constructed during the parent document's InitialReflow, triggered by the end of the document load.

So things are fine when the script executes only after the main document has finished loading.


While this is, technically, a regression of bug 1156, it's not really caused by that... <iframe>s should be broken even before that bug. all a consequence of the non-incremental XML content sink.

(some of those conclusions above are bz's :) )
This is basically bug 18333 -- when we need a layout object for the <object> it's just not there, since the parent is not done parsing yet and hence InitialReflow hasn't happened.

Note that we've had the same issue with <iframe> in XHTML since forever, and .screen will reliably fail in a display:none object or iframe no matter what we do...
Status: UNCONFIRMED → NEW
Depends on: incrementalxml
Ever confirmed: true
Though this bug still affects build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051108 Firefox/1.6a1 ID:2005110821, I guess it can still be closed as it's a duplicate of bug 18333?
No.  It's a separate bug.  Fixing bug 18333 might not fix this, but it'll make it possible to fix this.
Comment on attachment 199623 [details] [diff] [review]
Patch to try

I think we should still get this in.
Attachment #199623 - Flags: superreview?(jst)
Attachment #199623 - Flags: review?(jst)
Comment on attachment 199623 [details] [diff] [review]
Patch to try

r+sr=jst
Attachment #199623 - Flags: superreview?(jst)
Attachment #199623 - Flags: superreview+
Attachment #199623 - Flags: review?(jst)
Attachment #199623 - Flags: review+
Checked that in.  We still need an incremental sink.  :(
Attachment #199623 - Attachment is obsolete: true
(In reply to comment #41)
> Created an attachment (id=217652) [edit]
> Updated to tip; only partial fix still; checked in.
> 
> Checked that in.  We still need an incremental sink.  :(
> 

Better one step than no steps towards a final fix. ;) Roll on June-time for the fix for XML incremental content sink-age in bug 18333. :D
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Did that patch actually fix the testcase in this bug?
(In reply to comment #43)
> Did that patch actually fix the testcase in this bug?
> 

Retested in:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060409 Firefox/3.0a1 ID:2006040908
and
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060409 Firefox/3.0a1 ID:2006040908 [cairo]

Still seeing the issue, though given it depends on the content sink bug, I'll put this to sleep and come back to it at a later date, assuming it's still relevant.
per comment 31 this didn't fix the testcase. why was the bug resolved?
Yeah, this should be open until it's actually fixed.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This worksforme now....  Jonathan, are you still seeing it with a trunk build?
Yup, I see this as resolved on the following trunk build:

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a3pre) Gecko/20070302 Minefield/3.0a3pre ID:2007030205 [cairo]
Marking worksforme, as per comment 48 by the reporter. If someone can still reproduce this on trunk, please reopen.
Status: REOPENED → RESOLVED
Closed: 19 years ago → 18 years ago
Resolution: --- → WORKSFORME
Flags: in-testsuite?
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: