280390 - Ads/iframes sometimes steal keyboard focus (break change text size commands and page down)

Status: RESOLVED WORKSFORME

(Camino Graveyard :: General, defect, P3)

Description

[friscofrog]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

I have just noticed this on the latest nightlies but I can not say when it
started, but it is present in the Jan 29 and Jan 10 nightlies. The bug: When
going to
http://www.sfgate.com/cgi-bin/article.cgi?f=/news/archive/2005/01/29/international1529EST0541.DTL
the page loads correctly, but attempting to change the text size either by using
the menu bar command or the keyboard shortcut fails. Strangely enough going
stepping backward reveals the requested change and then subsequently going
forward the change persists in the page in which it was originally requested.

Reproducible: Always

Steps to Reproduce:
1.Go to
http://www.sfgate.com/cgi-bin/article.cgi?f=/news/archive/2005/01/29/international1529EST0541.DTL
2.Enter Cmd+ or Cmd-
3.Observe no text size change

Actual Results:  
Stepping backward reveals text size change in previous page which persists when
going forward again

Expected Results:  
Changed text size on page requested by menu bar or keyboard shortcut

Comment 1

[friscofrog]

I meant to say Cmd= not Cmd+ fails to increase text size. Cmd- fails to reduce
text size

Comment 2

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

Cmd=/Cmd- and menu equivs work just fine for me in the 2005012908 (v0.8+) Camino
nightly on 10.3.7.

Comment 3

[friscofrog]

I found this problem on two different computers with two different versions of
OS X (10.2.8 and 10.3.7) It only occurs on some links from the www.sfgate.com
site and not  on other sites. Also many links on the SFGATE home page open pages
that do text resize properly. Other browsers like Firefox and the released
Camino 0.8.2 do not have this problem with the problem links seen in the Jan 29
nightly and earlier.

Comment 4

[Hiro]

wfm Cmd+=/Ccmd+-

2005012921 (v0.8+)

Comment 5

[friscofrog]

On the Camino forum someone else confirmed this bug.It seems to be related to
javascript. If javascript is enabled the bug occurs on some links and is always
reproduceable with those links. If javascript is disabled bug disappears and
text resizing occurs as expected. There may be a relationship with bug 278916. I
also noted that disabling javascript affected bug 278916, in that bug an blank
smaller popup window appears along with a full new page with content. Disabling
javascript eliminated the blank popup window leaving only the larger new page.
The desired result is to have the content in the smaller popup window.

Comment 6

[friscofrog]

The bug seems to be related to the ad content of the page as well. Even if
javascript is enabled if CSS ad blocking is invoked using CEP the bug disappears.

Comment 7

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

I think it's safe to confirm this bug now.  I can see it when I remove my
userContent.css ad-blocking (and if I get the right ads served...).  

Here's a cogent diagnosis from smorgan from the MozillaZine forum thread about
this bug:

----

Ah, the reason it only happens sometimes is that it's related to the ads, which
are probably randomized. I can see it on the second like you posted, but if I
get rid of this line:

<SCRIPT language=JavaScript1.1
SRC="http://ad.doubleclick.net/adj/sf.gate/news;sect=news_sky;sz=160x600;
kw=WAR;ord=37755?"></SCRIPT><NOSCRIPT></NOSCRIPT>

the problem goes away. It looks like somehow the ads are eating the font change,
since I saw one ad's text size change while the rest of the page stayed the same. 

----

The Google ad-box at the bottom of the page referenced in comment 0 will
sometimes increase its text-size instead of the page, but other times some other
ad is stealing the command and even the Google ad box doesn't change text size....

Comment 8

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

*** Bug 300943 has been marked as a duplicate of this bug. ***

Comment 9

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

Switching in the url from the dupe, which I can get to cause this bug every 4th
reload or so; the original url (in comment 0) I could not get to demonstrate
this in about a dozen reloads, so it's possible the sfgate ad rotation has changed.

Note also that (at least with macosxhints) when this bug appears, bug 186746
seems to reappear; that is, the URLs of three ad iframes
http://www.macosxhints.com/bbm_ads/iframe_tile.php
http://www.macosxhints.com/bbm_ads/iframe_bigbox.php
http://www.macosxhints.com/bbm_ads/iframe_banner.php?
show up in the Go menu (not in the BM's history or in the session history on the
back button; only in the Go menu).

I'm guessing that's related?

Comment 10

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

I wonder if the latter part of comment 9 is bug 148794 (see bug 148794 comment 49)?

Comment 11

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

*** Bug 329527 has been marked as a duplicate of this bug. ***

Comment 12

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

This seems to be a more generalized focus-stealing problem; see the new dupe for details.

(I'm also unable to repro the original issue on macosxhints anymore...either it's vanished, or the ad servers have changed to be less focus-stealing)

Comment 13

[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 14

[philippe (part-time)]

Investigating this with current trunk builds:

* when the page is loaded in the foreground, current active tab, or in a new window, there are no problems at all that I could find.

Issues still arise when (the page focus is snatched by the iframe):
* when the page is loaded in a new (background) tab
or
* the page is loaded from a link in an email client or feed reader

main issues in those cases:

* page scroll from the keyboard fails (space bar or PgUp/PgDown)
*
   - tabbing through links (FKA turned ON) start inside the iframe;
   - if there are no links in the iframe, tab order start with the first focusable element on the toolbar;
but
   - Form controls can be focussed however.

I could not reproduce the issue with page/text-zoom mentioned above

Comment 15

[philippe (part-time)]

Attachment: test case

test case with empty iframe (enough to repro the issue with current trunk builds (2.0b1pre)).

There is also a link to arstechnica, when loaded in a new (background) tab focus is fetched by an ad (in iframe), even with current-at-time-of-writing adblocking turned on (see bug 459192 comment 4).

Comment 16

[philippe (part-time)]

On Gecko 1.9.2 builds, this appears to work correctly.

Comment 17

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

(In reply to comment #16)
> On Gecko 1.9.2 builds, this appears to work correctly.

WFM in 1.9.2-based nightlies, per comment 16 (modulo bug 563321).