Can not drag the first search engine in the listbox of Search Engine Manager

VERIFIED FIXED in Firefox 3.7a1

Status

()

VERIFIED FIXED
9 years ago
8 years ago

People

(Reporter: alice0775, Assigned: enndeakin)

Tracking

({regression})

3.6 Branch
Firefox 3.7a1
regression
Points:
---
Bug Flags:
in-testsuite ?
in-litmus +

Firefox Tracking Flags

(status1.9.2 ?)

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b2pre) Gecko/20091021 Firefox/3.5.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2b2pre) Gecko/20091021 Namoroka/3.6b2pre ID:20091021050746

When I sort search engines,
I can not drag the first search engine in the listbox of Search Engine Manager

Reproducible: Always

Steps to Reproduce:
1.Start Namoroka with new profile
2.Click search engine icon and select 'Manage Search Engines…' in the dropdown.
3.Drag the first search engine(Google) in the listbox

Actual Results:  
Could not drag.

Expected Results:  
Can drag.

The bug happens on trunk build also
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.3a1pre) Gecko/20091021 Minefield/3.7a1pre ID:20091021043213
(Reporter)

Updated

9 years ago
Keywords: regression
Version: unspecified → 1.9.2 Branch
(Reporter)

Updated

9 years ago
Component: XUL → Search
Product: Core → Firefox
Version: 1.9.2 Branch → 3.6 Branch
(Reporter)

Comment 1

9 years ago
This issue dissolves by modifying content\browser\search\engineManager.js as follows

function onDragEngineStart(event) {
  var selectedIndex = gEngineView.selectedIndex;
-  if (selectedIndex > 0) {
+  if (selectedIndex > -1) {
    event.dataTransfer.setData(ENGINE_FLAVOR, selectedIndex.toString());
    event.dataTransfer.effectAllowed = "move";
  }
}
QA Contact: xptoolkit.widgets → search
Regression from the new D&D API which has been implemented in bug 456106.

Alice, would you be able to create a real patch against the trunk source?
Blocks: 456106
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows Vista → All
Hardware: x86 → All
(Reporter)

Comment 3

9 years ago
(In reply to comment #2)
> Alice, would you be able to create a real patch against the trunk source?
Sorry, I am not familiar with source tree.
Would you mind to get the knowledge? There are some simple steps involved which are described in detail on MDC: https://developer.mozilla.org/en/Creating_a_patch
(Reporter)

Comment 5

9 years ago
(In reply to comment #4)
> Would you mind to get the knowledge? There are some simple steps involved which
> are described in detail on MDC:
> https://developer.mozilla.org/en/Creating_a_patch
PleasePlease ask other person.
(Assignee)

Comment 6

9 years ago
Created attachment 411129 [details] [diff] [review]
patch as above

Is there a test for the search engine dialog?
Assignee: nobody → enndeakin
Status: NEW → ASSIGNED
Attachment #411129 - Flags: review?(rflint)
(In reply to comment #6)
> Is there a test for the search engine dialog?

Not that I'm aware of. I only know about the tests in the folder below which doesn't test the engine. Ryan, can you help?

http://mxr.mozilla.org/mozilla1.9.1/source/browser/components/search/test/
Attachment #411129 - Flags: review?(rflint) → review+
Comment on attachment 411129 [details] [diff] [review]
patch as above

(In reply to comment #6)
> Created an attachment (id=411129) [details]
> patch as above
> 
> Is there a test for the search engine dialog?

Nope!
(In reply to comment #8)
> > Is there a test for the search engine dialog?
> 
> Nope!

Let's flag for a request. Meanwhile I will add it to Litmus.
Flags: in-testsuite?
Flags: in-litmus?
Target Milestone: --- → Firefox 3.7a1
(Assignee)

Comment 10

9 years ago
http://hg.mozilla.org/mozilla-central/rev/bd0b08574d1a
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED
(Reporter)

Comment 11

9 years ago
This issue is not fixed yet in Firefox3.6.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.2pre) Gecko/20100218 Namoroka/3.6.2pre ID:20100218052130
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
status1.9.2: --- → ?
Target Milestone: Firefox 3.7a1 → ---
Right, it's not fixed for 3.6 but this is tracked by the approval request. So lets close this bug.

Neil, is your patch ready for asking approval1.9.2.2?
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 3.7a1
Verified fixed on trunk with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a2pre) Gecko/20100221 Minefield/3.7a2pre ID:20100221031108
Status: RESOLVED → VERIFIED
The following Litmus test has been updated to cover that particular regression:
https://litmus.mozilla.org/show_test.cgi?id=10233

(In reply to comment #12)
> Neil, is your patch ready for asking approval1.9.2.2?

Neil, any update or wont we be able to fix it on 1.9.2 due to regulations?
Flags: in-litmus? → in-litmus+
(Assignee)

Comment 15

8 years ago
I tested the patch and it works fine. Ask for approval if this is desired but probably isn't worth it at this point.
You need to log in before you can comment on or make changes to this bug.