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

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

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

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.

wfm Cmd+=/Ccmd+- 2005012921 (v0.8+)

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.

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.

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....

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

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?

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

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

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)

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*.

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

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).

On Gecko 1.9.2 builds, this appears to work correctly.

(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).