Closed Bug 639175 Opened 9 years ago Closed 9 years ago

Unable to refine searches on Y! Answers


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

Not set



Tracking Status
blocking2.0 --- Macaw+
status2.0 --- .1-fixed


(Reporter: mofoxfirezilla, Assigned: mounir)




(Keywords: regression)


(1 file, 1 obsolete file)

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
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.
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:
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 635008
Keywords: regression
Version: unspecified → Trunk
Hi. Unfortunately, the problem the same unsolved with FF 4 RC1.
Resolution: DUPLICATE → ---
Could you see if the issue occurs if using Firefox in safe mode:

How about with a new, empty testing profile? (Don't install any addons into it)
Blocks: 635008
new profile on rc1 = same problem
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...
Blocks: 551846
No longer blocks: 635008
blocking2.0: --- → ?
Ever confirmed: true
Component: General → DOM: Core & HTML
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → general
Hardware: x86 → All
Attached patch Allow select.size=0 (obsolete) — Splinter Review
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.
Assignee: nobody → mounir.lamouri
Attachment #518371 - Flags: review?(Olli.Pettay)
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...
Whiteboard: [has patch][needs review]
Comment on attachment 518371 [details] [diff] [review]
Allow select.size=0

># HG changeset patch
># Parent 30f82a8fb63e1de481d00f96cdbd83e72d2dc7e7
># User Mounir Lamouri <>
># 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_INT_ATTR(nsHTMLSelectElement, TabIndex, tabindex)
> 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
Attachment #518371 - Flags: review?(Olli.Pettay) → review+
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.
blocking2.0: ? → .x+
Whiteboard: [has patch][needs review]
(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?
Blocks: 640800
And a third bug: bug 640800.
I guess everyone was hiding select.size=0 bugs and yesterday was the release date...
(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"
This change was definitely not web compatible. I've open a bug against the specs:

I'm going to update the tests.

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
Attachment #518371 - Attachment is obsolete: true
Whiteboard: [can land][post-2.0][passed-try]

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

I see FF4 got pushed out today!
Adam, this will be in Firefox 5 in a few months, if everything goes to plan.
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 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?
Attachment #518754 - Flags: approval2.0?
Whiteboard: [can land][post-2.0][passed-try] → [needs approval][post-2.0][passed-try]
Pushed on trunk:

So this should be fixed in Firefox 5. It could be fixed in a minor 4.x release if the patch is approved.
Closed: 9 years ago9 years ago
status2.0: --- → ?
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: [needs approval][post-2.0][passed-try] → [needs approval]
Target Milestone: --- → mozilla2.2
status2.0: ? → ---
Ever confirmed: false
Resolution: FIXED → ---
Whiteboard: [needs approval] → [needs approval][needs branch]
Target Milestone: mozilla2.2 → ---
Mounir, did you mean to reopen this and set it unconfirmed?
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Restoring the rest.
status2.0: --- → ?
Whiteboard: [needs approval][needs branch] → [needs approval]
Target Milestone: --- → mozilla2.2
Whiteboard: [needs approval] → [needs approval][needs branch]
blocking2.0: .x+ → Macaw
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
Attachment #518754 - Flags: approval2.0? → approval2.0+
(In reply to comment #24)
> Pushed in mozilla-2.0 branch:

That means it should be fixed in Firefox 4.0.1.
Whiteboard: [needs approval][needs branch]
You need to log in before you can comment on or make changes to this bug.