User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040911 Firefox/0.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040911 Firefox/0.10 In the Whasington Post page, every key stroke reloads the page. The 'find as you type' line appears briefly and then disappears. Reproducible: Always Steps to Reproduce: 1. 2. 3. blocking-aviary1.0PR

You're not allowed to mark blocking flags as +/- only as ? Clearing the blocking+ flag. You might want to actually have the bug confirmed first, before requesting blocking. 1.0PR is basically done, its highly unlikely this will be +'ed for PR.

sorry about that. Requesting now.

The find bar resizes the page. A script on the Washington Post front page makes it reload when resized (dumb but common). As a result, using Find makes the page reload. See also bug 252306, similar problem with Information Bar for blocked popups.

this doesn't have any major impact. It happens with anything (adding/removing toolbars, opening the sidebar, the find toolbar) that changes the size of the content area. Even resizing the content area causes a refresh. minusing blocker nomination, since its not a stopper at this stage, and is probably WONTFIX, since the same problem exists with sidebars, toolbar changes, window resizing...

I'd like to strongly suggest against WONTFIX (non-blocking is understandable for 1.0PR thou requesting for 1.0). The difference between having a reload caused by using Find and having one caused by sidebar, toolbar, and resize changes is that the find situation is (along with Bug 252306) in which these visual elements should not be considered an adjustment to the size of the window content. The other changes (resize window, toolbar, etc) are more permanent changes to the content area.

I agree. In addition, IMHO the severuty of the bug should be higher then minor. The bug actually prevents people from using 'find as you type' in a page that reloads on resize. It seems to me that a basic feature is not working here.

A workaround is to open the find bar manually (Ctrl-F, at least in Windows), which will reload the page once but leave the bar up. Then find works as expected. I'd still vote against WONTFIX for this one though.

This bug is major, since if you have several tabs open, and press ctrl + f on a website that has these kind of script not only reloads the current tab, but also *other* inactive tabs. Just open several tabs go to www.washingtonpost.com and press ctrl + f, see not only the current tab reload, but also other inactive tabs.

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

This is a *major* bug and certainly worthy of blocking status, imho. Find is *completely* broken for many, many sites (all those where resizing causes a reload) when using tabs. It basically comes down to how people use tabs. If you use tabs by opening "articles" in a new tab while visiting a site, find is COMPLETELY broken and, therefore, so is Firefox. If you browse as if tabs didn't exist, of course, you don't have much of a problem. Try opening www.nfl.com or www.f1racing.net (two premier, high-volume sports-sites) and open articles in 4-5 tabs. Then try pressing CTRL-F to search for something. BANG. Hope you aren't on a slow connection or that the sites aren't bogged down (as, e.g., nfl.com is every sunday during games). It really astounds me that such a fundamental change is made to the way Firefox works *right* before 1.0. That's really bizar. And it's not like the changes are in any way completely implemented - e.g. search when viewing source is still done the old way. Is there *any* reason not to float the search bar? There may well be, browser habbits differ... but the question is serious enough. Even if you want the "bar" look, why not just float it (i.e. draw it on top of the content, thereby not forcing reloads). MAJOR BUG! Sorry if I sound frustrated, but this really is making Firefox extremely annoying to use.

anyone have thoughts on how a fix might work? we would need a well test patch to consider this for 1.0

Here's an easy fix: FLOAT THE FIND BAR! If one happens to like the current look, fine, then keep the current "bar" look. But since the bar isn't a fully functional bar anyway (e.g. cannot be moved to top, at least through current interface), there seems little reason NOT to float it. I, personally, cannot think of any instance where one would NOT want the find toolbar to be floating. (By floating, I mean simply that it is just rendered on top of the page). If that isn't possible, for whatever reason, I would strongly suggest reverting to the old find. At least it worked. (And it's still present when viewing source). One thing: It seems really odd to introduce a new feature, which is what this bar is, so late in the game. It really does seem to go against everything I've learned about project management over the years. Sincerely, fyo

I think this is a serious bug not just because it breaks find as you type, but because it can cause reloads to multiple tabs. 4-5 simultaneous reloads stress the browser and the network connection with no warning. Although it only seems to reload tabs from the same website (because of the underlying javascript calling the reload?) it is still a very jarring and frustrating surprise to the user.

Here are some more websites where starting/stopping find reloads the page: http://www.interactivebrokers.com/php/main.php http://careers.peopleclick.com/Client40_GLDTR/bu1/External_Pages/Careers.htm and all tabs are affected even if on different websites than the current tab. This is annoying on a broadband connection, much worse on dialup. Personally I like the new find toolbar, you can't lose the word you are looking for under the dialog box. However it does make 'find as you type' close to useless. I agree that this is more than a minor bug.

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

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

*** This bug has been marked as a duplicate of 227361 ***

Reopening. This bug, as reported in comment 0, is still present. The fix for bug 227361 fixes it so the current tab is the only one resized when the find bar appears, but the current tab is still resized. Undoing the summary-munging that totally mutated the bug. I wish people wouldn't spam bugs with unrelated comments; half the comments on this one are actually about bug 227361, not THIS bug. FWIW, I agree that this bug is pretty serious -- an important piece of browser accessibility functionality (FAYT) is simply broken on this site. Ccing aaronlev.

Renominating. While I agree with mconnor that resizing should reload the page, there is no a-priori reason that FAYT or Find should cause resizing. So I would very strongly oppose WONTFIXing this, and due to the accessibility implications I feel this is serious enough to warrant reconsideration for 1.0.

So, this probably isn't something we'd want to do for the branch, but... The location.reload() onresize hack is something that was done by many sites for Netscape 4.x, although there's a change some sites may have done it for Mozilla as well. Would it be evil if we hacked any location.reload() triggered from an onresize handler to do a style change reflow instead of reloading the document?

I'll see how effective evangeliziing them will be.

I was also talking to bclary about the possibility of envangelizing some of the top sites that are tough to use FAYT.. he mentioned there are plenty of sites that still use appname == "Netscape" to do this onresize stuff though. does anyone have a list of sites outside washingtonpost.com that seem to have problems?

Frankly, I would just be in favor of disabling reload() from resize altogether. I don't see a good reason to do anything more than our standard resize reflow there. I believe sites had this hacked for NS4 because NS4 would actually lose CSS styling on resize.... We're just being caught by silly sites testing for appName == "Netscape" here.

(In reply to comment #20) [...] > Would it be evil if we hacked any location.reload() triggered from an onresize > handler to do a style change reflow instead of reloading the document? Yeah, kinda, but what the sites are doing is evil too :) Wouldn't we simply need to make location.reload() (n' friends) to do nothing, the resize already happened...

Maybe something like this?

Is there a reason we're dropping the call on the floor even if one window calls it on another one? Apart from that, the patch looks good.

Comment on attachment 162618 [details] [diff] [review] Make location.reload() and history.go(0) no-np's when called from onresize >+ // history.go(0) (aka location.reload()) was called while >+ // handling a resize event. Sites do this since Netscape 4.x >+ // needed it, but we don't, and it's a horrible experience for >+ // nothing, so drop the call on the floor. >+ >+ return NS_OK; I'm not crazy about this bit. Some web authors may actually do it to work around our incremental reflow bugs, since it's the trick they happen to know. So perhaps you could call ClearStyleDataAndReflow on the 0th pres shell's pres context?

Comment on attachment 162631 [details] [diff] [review] Clear style data and trigger reflow in stead of reloading. Um, close, but no sigar. New version on its way.

(In reply to comment #26) > Is there a reason we're dropping the call on the floor even if one window calls > it on another one? Hmm, I don't know that I care either way. The common case we care about is the window resizing itself. Do you think other cases matter?

The other cases are one window responding to a resize of another one... I'd think we want to keep current behavior in those cases, no?

Comment on attachment 162648 [details] [diff] [review] Clear style data and trigger reflow in stead of reloading. (trunk diff) Yeah, this I like. r=bzbarsky.

Comment on attachment 162648 [details] [diff] [review] Clear style data and trigger reflow in stead of reloading. (trunk diff) Fix landed on the trunk. Now the big question is if we'll want this on the aviary branch... I kinda think we do, dbaron didn't seem to be so sure...

quick search of te bugs for resize/reload Bug 147351 thestreet.com - Bad autoload when opening new web page Bug 201710 hmco.com - Reloads if I resize window Bug 241165 washingtonpost.com refreshes on resize Bug 106991 intelihealth.com - unable to maximize oddly sized webpage I can't vouch for the safety of this patch on aviary 1.0 but it would be an incremental improvement for general mozilla users. The fact that Firefox changes the window size for Find as you type may mean it is more important for Firefox than Seamonkey. If you are interested, it would be possible to spider a bunch of sites and send resize events to the page to check for major crash issues etc and to perhaps capture onunload to see how many pages this would affect. This type of testing would not cover web apps or intranet based content however. I would be happy to help someone with a faster/low latency connection do the testing.

Comment on attachment 162648 [details] [diff] [review] Clear style data and trigger reflow in stead of reloading. (trunk diff) a=chofmann for the branch after discussion with all today

Fixed on trunk and aviary branch.

What about 1.7?

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

looks good using 2004102508-0.9+ on linux fc2.

Moving to Browser/DOM

Comment on attachment 162648 [details] [diff] [review] Clear style data and trigger reflow in stead of reloading. (trunk diff) 1.7 is OK.

Fixed on the 1.7 branch.

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

Is this a temporary fix or workaround solution to the problem? I agree to comment #12 and partly #19, which says the FInd bar should FLOAT over the page. THis would solve the problem of a page getting resized and thus, avoid the overhead of these workarounds such as disabling the reload on resize. We could concentrate on fixing the Find toolbar UI?

(In reply to comment #46) > Is this a temporary fix or workaround solution to the problem? I agree to > comment #12 and partly #19, which says the FInd bar should FLOAT over the page. > THis would solve the problem of a page getting resized and thus, avoid the > overhead of these workarounds such as disabling the reload on resize. We could > concentrate on fixing the Find toolbar UI? Whether this is considerd a workaround fix or a complete fix for the problem we still want to keep this fix to prevent sites that reload on resize from doing that as the reasons for doing that are no longer valid in Mozilla (never was, in fact, old Netscape 4.x leftovers).

Note that some sites actually depended on writing out new style onload after the reload... see bug 275231.

This is a pain for me. I want to resize my window content when the window is resized. It works fine on IE and Netscape but not Firefox. Any suggestions of a workaround for your bug-fix? Ned Gayner