Closed Bug 258917 Opened 16 years ago Closed 16 years ago

Find As You Type not working on Washington Post page.

Categories

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

defect
Not set
major

Tracking

()

VERIFIED FIXED

People

(Reporter: orend, Assigned: jst)

References

()

Details

(Keywords: access, fixed-aviary1.0, fixed1.7, Whiteboard: [has patch] see if there is something we can do... evangelize?)

Attachments

(3 files, 1 obsolete file)

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
Flags: 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.
Flags: blocking-aviary1.0PR+
sorry about that. Requesting now.
Flags: blocking-aviary1.0PR?
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: find as you type causes reloads of page → Find Toolbar causes reload on sites that reload on resize
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...
Severity: major → minor
Status: NEW → ASSIGNED
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
Summary: Find Toolbar causes reload on sites that reload on resize → changing content area size causes reloads of page
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.
Flags: blocking-aviary1.0?
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.
Severity: minor → major
Summary: changing content area size causes reloads of page → changing content area size causes reloads of page + 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
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Flags: blocking-aviary1.0+ → blocking-aviary1.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 ***
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
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.
Status: RESOLVED → REOPENED
Keywords: access
Resolution: DUPLICATE → ---
Summary: changing content area size causes reloads of page + inactive tabs → Find As You Type not working on Washington Post page.
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.
Flags: blocking-aviary1.0- → blocking-aviary1.0?
OS: Windows XP → All
Hardware: PC → All
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?
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Whiteboard: see if there is something we can do... evangelize?
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...
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.
Attachment #162631 - Attachment is obsolete: true
(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?
Attachment #162648 - Flags: superreview?(dbaron)
Attachment #162648 - Flags: review?(bzbarsky)
Assignee: firefox → jst
Status: REOPENED → NEW
Attachment #162648 - Flags: superreview?(dbaron) → superreview+
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.
Attachment #162648 - Flags: review?(bzbarsky) → review+
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...
Attachment #162648 - Flags: approval-aviary?
Whiteboard: see if there is something we can do... evangelize? → [has patch] see if there is something we can do... evangelize?
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
Attachment #162648 - Flags: approval-aviary? → approval-aviary+
Fixed on trunk and aviary branch.
Status: NEW → RESOLVED
Closed: 16 years ago16 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
*** Bug 259012 has been marked as a duplicate of this bug. ***
looks good using 2004102508-0.9+ on linux fc2.
Status: RESOLVED → VERIFIED
Moving to Browser/DOM
Component: Find Toolbar / FastFind → DOM
Product: Firefox → Browser
Version: unspecified → Trunk
Attachment #162648 - Flags: approval1.7.x?
Comment on attachment 162648 [details] [diff] [review]
Clear style data and trigger reflow in stead of reloading. (trunk diff)

1.7 is OK.
Attachment #162648 - Flags: approval1.7.x? → approval1.7.x+
Fixed on the 1.7 branch.
Keywords: fixed1.7
*** 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.
Flags: review+
Blocks: 285439
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
Component: DOM → DOM: Core & HTML
Regressions: 1570566
You need to log in before you can comment on or make changes to this bug.