288894 - Floating ad locks up Camino (except for dragging the browser window title bar)

Status: VERIFIED WORKSFORME

(Camino Graveyard :: General, defect, P1)

Description

[Mark]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050331 Camino/0.8.3
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.6) Gecko/20050331 Camino/0.8.3

Absolutely nothing works when this floating ad is running, EXCEPT grabbing the
title bar and dragging. Not the close/minimize/expand buttons, not clicking on
the ad, not clicking in the browser window any where, not any of the menus, not
any of the keyboard short cuts.

Reproducible: Always

Steps to Reproduce:
1. Open the URL Above
2.
3.

Actual Results:  
Same

Expected Results:  
Worked

Comment 1

[Samuel Sidler (old account; do not CC)]

Wow... nice find. I'm confirming this using the nightly from 2005032108.

Comment 2

[Mark]

(In reply to comment #1)
> Wow... nice find. I'm confirming this using the nightly from 2005032108.

Cool. Glad it wasn't just me. 

I'm also seeing some pop-up's not being blocked, but I'll have to keep looking
at that one because it is intermittant, and can't tell if it is every time yet.
I'll look into the bug site later if I find more.

mark

Comment 3

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

That is supremely evil.  And it's Camino-only; the 20050403 Firefox can actually
click on the "Click me" text to get it to go away (if you're fast enough), and
the menus and chrome are all responsive.

As a work-around in Camino, you can use any of the entries in your Dock menu to
navigate away from that site.

Comment 4

[Mark]

(In reply to comment #3)
> That is supremely evil.  And it's Camino-only; the 20050403 Firefox can actually
> click on the "Click me" text to get it to go away (if you're fast enough), and
> the menus and chrome are all responsive.
> 
> As a work-around in Camino, you can use any of the entries in your Dock menu to
> navigate away from that site.

Yeah, I tested it in Firefox, Safari, and NN 7 and they all work. Cool, I'll
give that a go.

Comment 5

[Mike Pinkerton (not reading bugmail)]

if you run sampler or shark, what is the app doing? is there a spinning wheel or
is it just locked?

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: Gzipped sample of Camino at aimoo

I don't know how to run shark :-( but there's no spinning wheel displayed when
simply viewing the page.   Here's a sample from Activity Monitor while
displaying the page and its silly moving "click me" thing (the default sample
was too large for bugzilla as plain text, so it's gzipped).

Note that when you use Camino's Dock menu to open a new window, the UI is
unlocked (although switching back to the window contianing the moving "click
me" locks up the UI again)

Comment 7

[Echidnae]

Would this bug have anything to do with the crash I'm getting when I try and
access http://powweb.com ?  It has some sort of floating ad-type thing, and
whenever I try to access the page, before it loads, Camino crashes.  I'm using
2005042408 when this is happening.

Comment 8

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: crash log from loading http://powweb.com

(In reply to comment #7)
> Would this bug have anything to do with the crash I'm getting when I try and
> access http://powweb.com ?  It has some sort of floating ad-type thing

Perhaps; the floating thing is similar, even though powweb's is not moving (at
least not in Fx) and crashes rather than hangs.

Here's the crashlog from starting to load http://powweb.com

Comment 9

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: aimoo source

The powweb.com thing was another issue, long since fixed.  

If you're accessing a menu or something when this page starts loading, then
Camino locks up, locks up the dock, and does require a force quit.

The relevant code seems to be this div
<div id="img" style="position:absolute;left:27px;top:5px;z-index:100">
which contains the table which contains table and iframe for the ad/"Close Me"
bit
<a href="javascript:" onclick="img.style.visibility='hidden';return
false;">Close Me</a> 
and some of the JavaScript that follows (which I assume controls the
movement)...all of which are nested in a couple of tables.

I'm gonna put this on the 1.0 list for investigation then.  It's Camino-only,
essentially causes a hang, but doesn't seem to be widespread.

Comment 10

[Simon Fraser [no longer active]]

The problem here is that the page has a floating <div> that is moved every 30ms.
Camino suffers worse than Firefox because our drawing is slower (see bug
166932), but it's odd that user events don't get "queued up" and handled eventually.

Maybe we should just block that iframe id in our ad_blocking.css :)

Comment 11

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Comment on attachment 190072 [details]
aimoo source

Editing the attachment MIME type so that viewing it (to see the page source)
doesn't cause Camino to hang :)

As for comment 10, Camino does queue the user events; they just don't get
handled until you find a way to exit the page (Dock menu); then tab-switches
and view-sources and whatnot all happen!

Comment 12

[Torben]

URL is gone and I don't get any lockups when loading attachment 190072 [details] (as html) (2005111504 (v1.0b1+) 10.2.8)

Comment 13

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

The problem still exists when loading the source as HTML in the build I have on the road with me, 2005111804 (v1.0b1+), 10.3.9; you can't ever get the click through to the "close me".

Comment 14

[Torben]

Strange, I can reproduce the lockup on my 10.3.9 machine.

Comment 15

[froodian (Ian Leue)]

[12:48am] <ardissone|away> that one can prolly be pushed off, but someone needs to profile it at some point
[12:48am] <ardissone|away> actually, someone should check it in 181 and trunk to see if any event model changes have helped

Comment 16

[Torben]

I can't reproduce on recent trunk build, the latest 181-branch nightly (and 1.0.2) still locks up. OS X 10.3.9

Comment 17

[Stuart Morgan]

How is this for everyone on trunk? If this is a "our drawing system is problematic" issue that's fixed on trunk we just WFM it, since we aren't going to do any significant drawing work on branch.

Comment 18

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Mass un-setting milestone per 1.6 roadmap.

Filter on RemoveRedonkulousBuglist to remove bugspam.

Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.

Comment 19

[Stuart Morgan]

Looks good in trunk for me as well (it could be a bit smoother, but no UI lock up), so closing WFM.

Comment 20

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Heh, even WFM in my old trunk build.  It's either part of the more substantial event model work that landed on the trunk and was not in the branch subset, or the drawing stuff Stuart mentioned in comment 17.