639175 - Unable to refine searches on Y! Answers

Status: RESOLVED FIXED

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

Description

[mofoxfirezilla]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b12) Gecko/20100101 Firefox/4.0b12

The category's spinner loads forever when refining your search which blocks you from refining your search based on categories.

Reproducible: Always

Steps to Reproduce:
1. Go to http://answers.yahoo.com/
2. Type anything in "What are you searching for?", click on "Search Y! Answers"
3. Under "Refine search", Under "Category", choose any category that has sub-categories, e.g. Arts & Humanities.
4. The spinner shows up and loads forever.
Actual Results:  
Sub-categories are not showing up (spinner loads forever). You can't search a category unless it works.

Expected Results:  
Sub-categories to show up so you can refine your search.

FF 4 Beta 12 / Win XP
Created new profile = same problem.
On IE = works fine.

Comment 1

[Ed Morley [:emorley]]

A problem with the category page was fixed since beta 12, in bug 635008.

Please try with the release candidate when it is released (in the next few days), or else try the latest nightly:
http://nightly.mozilla.org/

Comment 2

[mofoxfirezilla]

Hi. Unfortunately, the problem the same unsolved with FF 4 RC1.

Comment 3

[Ed Morley [:emorley]]

Could you see if the issue occurs if using Firefox in safe mode:
http://support.mozilla.com/kb/Safe+Mode

How about with a new, empty testing profile? (Don't install any addons into it)
http://support.mozilla.com/kb/Basic+Troubleshooting#w_make-a-new-profile

Comment 4

[mofoxfirezilla]

new profile on rc1 = same problem

Comment 5

[Mounir Lamouri (:mounir)]

This is because of bug 551846. Since this patch has been pushed, you can't set select.size to 0 or less. Obiously, Yahoo Answers try to do that...

Comment 6

[Mounir Lamouri (:mounir)]

Attachment: Allow select.size=0

That's sad because this change has been made 10 months ago...

So, Webkit and Opera allow any value for select.size and IE6 to 9 do not allow negative values.

This patch is very simple and make us behave like IE. IOW, we know allow size=0. That's what Yahoo Answers was trying to do and that is fixing the breakage.

Comment 7

[Mounir Lamouri (:mounir)]

Johnny, What should we do with that bug? Can it go for final given that it's very simple or should we only push it if we build a RC2? or even wait for a minor release?

I'm assuming Yahoo Answers! isn't the kind of websites we want to break...

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 518371 [details] [diff] [review]
Allow select.size=0

># HG changeset patch
># Parent 30f82a8fb63e1de481d00f96cdbd83e72d2dc7e7
># User Mounir Lamouri <[e-mail]>
># Date 1299769558 -3600
>Bug 639175 - Allow select.size=0.
>
>diff --git a/content/html/content/src/nsHTMLSelectElement.cpp b/content/html/content/src/nsHTMLSelectElement.cpp
>--- a/content/html/content/src/nsHTMLSelectElement.cpp
>+++ b/content/html/content/src/nsHTMLSelectElement.cpp
>@@ -1265,17 +1265,17 @@ nsHTMLSelectElement::SetValue(const nsAS
> }
> 
> 
> NS_IMPL_BOOL_ATTR(nsHTMLSelectElement, Autofocus, autofocus)
> NS_IMPL_BOOL_ATTR(nsHTMLSelectElement, Disabled, disabled)
> NS_IMPL_BOOL_ATTR(nsHTMLSelectElement, Multiple, multiple)
> NS_IMPL_STRING_ATTR(nsHTMLSelectElement, Name, name)
> NS_IMPL_BOOL_ATTR(nsHTMLSelectElement, Required, required)
>-NS_IMPL_POSITIVE_INT_ATTR_DEFAULT_VALUE(nsHTMLSelectElement, Size, size, 0)
>+NS_IMPL_NON_NEGATIVE_INT_ATTR_DEFAULT_VALUE(nsHTMLSelectElement, Size, size, 0)
> NS_IMPL_INT_ATTR(nsHTMLSelectElement, TabIndex, tabindex)
> 
> NS_IMETHODIMP
> nsHTMLSelectElement::Blur()
> {
>   return nsGenericHTMLElement::Blur();
> }
> 
>diff --git a/content/html/content/test/test_bug551846.html b/content/html/content/test/test_bug551846.html
>--- a/content/html/content/test/test_bug551846.html
>+++ b/content/html/content/test/test_bug551846.html
>@@ -95,17 +95,17 @@ function checkSetSizeException(element)
>   ok(!caught, "Setting a valid size shouldn't throw an exception");
> 
>   caught = false;
>   try {
>     element.size = 0;
>   } catch(e) {
>     caught = true;
>   }
>-  ok(caught, "Setting an invalid size from the IDL should throw an exception");
>+  todo(caught, "Setting an invalid size from the IDL should throw an exception");

If we take this change, could you please check what the value of element.size is after setting it.
Also, since our current behavior is what HTML spec requires, please file a spec bug and link it to here
too.

Comment 9

[Mike Beltzner [:beltzner, not reading bugmail]]

This is a site-related issue, been around since March, we can try to put a workaround in a .x version, but won't block final release for it.

Comment 10

[Mounir Lamouri (:mounir)]

(In reply to comment #9)
> This is a site-related issue, been around since March, we can try to put a
> workaround in a .x version, but won't block final release for it.

It seems that this issue is also breaking jQuery when calling removeAttr() on select.size, see bug 640636. Does that change something?

Comment 11

[Mounir Lamouri (:mounir)]

And a third bug: bug 640800.
I guess everyone was hiding select.size=0 bugs and yesterday was the release date...

Comment 12

[Ed Morley [:emorley]]

(In reply to comment #11)
> I guess everyone was hiding select.size=0 bugs 

That or people are utilising the old favourite routine: "Let's wait until the release candidate before even starting to test our site/product with soon to be released browser/OS/platform X"

Comment 13

[Mounir Lamouri (:mounir)]

This change was definitely not web compatible. I've open a bug against the specs:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12288

I'm going to update the tests.

Comment 14

[Adam Stylo]

Ed,

In our case it was "lets test FF4 asap" (some time last year), then "oh s*%t it is 2011 already, they have RC1, this needs to be done NOW"....

Not sure what Yahoo's excuse is .... 

Anyway - thanks for jumping to action guys. We love you FF :-D even if we ignored your beta for a few months :-D

Comment 15

[Mounir Lamouri (:mounir)]

Attachment: Allow select.size=0 (with updated tests)

r=smaug

Comment 16

[Adam Stylo]

Mounir,

Do you know what version this fix will go out in?

I see FF4 got pushed out today!

Comment 17

[Boris Zbarsky [:bzbarsky]]

Adam, this will be in Firefox 5 in a few months, if everything goes to plan.

Comment 18

[Adam Stylo]

I hope you guys can consider pushing it out in a 4.x release sooner!  It might not be breaking a lot of sites, but it got broken between FF v3.6 and v4.0.... IE9 works fine on that particular issue.

Comment 19

[Mounir Lamouri (:mounir)]

Comment on attachment 518754 [details] [diff] [review]
Allow select.size=0 (with updated tests)

This patch seems pretty safe and the bug breaks quite a few stuff. Can't we have it pushed in a 4.x release?

Comment 20

[Mounir Lamouri (:mounir)]

Pushed on trunk:
http://hg.mozilla.org/mozilla-central/rev/24714b2ebd4f

So this should be fixed in Firefox 5. It could be fixed in a minor 4.x release if the patch is approved.

Comment 21

[Boris Zbarsky [:bzbarsky]]

Mounir, did you mean to reopen this and set it unconfirmed?

Comment 22

[Ed Morley [:emorley]]

Restoring the rest.

Comment 23

[Daniel Veditz [:dveditz]]

Comment on attachment 518754 [details] [diff] [review]
Allow select.size=0 (with updated tests)

Approved for the mozilla2.0 repository, a=dveditz for release-drivers

Comment 24

[Mounir Lamouri (:mounir)]

Pushed in mozilla-2.0 branch:
http://hg.mozilla.org/releases/mozilla-2.0/rev/b5a576b9a3e0

Comment 25

[Mounir Lamouri (:mounir)]

(In reply to comment #24)
> Pushed in mozilla-2.0 branch:
> http://hg.mozilla.org/releases/mozilla-2.0/rev/b5a576b9a3e0

That means it should be fixed in Firefox 4.0.1.