Closed Bug 77345 Opened 23 years ago Closed 22 years ago

browser window can't display too many multiple search engines at once

Categories

(SeaMonkey :: Search, defect, P2)

x86
Windows NT
defect

Tracking

(Not tracked)

VERIFIED FIXED
Future

People

(Reporter: lynnw, Assigned: samir_bugzilla)

References

(Blocks 1 open bug)

Details

Attachments

(4 files, 1 obsolete file)

If a user selects around 5 or 6 search engines to perform a search from the 
sidebar, the main browser window cannot display all of the search engines. The 
search engines get cut off on the right-hand side. Also note that there is no 
horizontal or vertical scrollbar to allow the user to view all of the engines 
and results. Please see attachment for more details.

What about just showing the buttons for each search engine in the browser window 
like you already do, but put them in a vertical column instead of horizontally? 
Then, when the user clicks on a search engine button, the results pop up along 
side the vertical row of buttons? You would just have two columns: one for the 
buttons and one for the result page. 

Using 800 x 600 resolution only allows me to view one of the search engine 
buttons. I think that there are still quite a few users that have 15 to 17" 
screens and have their settings at 800 x 600. I know that my machine at home is 
set to this resolution, since anything smaller is harder to read. The only way 
the end-user will see more than one (or two) buttons at this resolution would be 
to close the sidebar.
Keywords: nsbeta1
Adding Michael Laguardia. Hope you're the right person for this kind of issue.
This is a new bug based on an older commercial bug that will be moved to 
Bugscape. This is for the Mozilla project.
nav triage: this is not a beta stopper for Netscape. 
Keywords: nsbeta1nsbeta1-
I had the same pb with earlier version on Linux
This bug seems to be fixed (0.9.2.1 Linux)
<triage> samir and claudius think that a dropdown is the right control to solve
this problem - instead of buttons.
Assignee: matt → sgehani
Priority: -- → P2
Target Milestone: --- → mozilla0.9.6
Moving to mozilla0.9.7.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
-> mozilla0.9.8
Really moving to mozilla0.9.8.  Sorry for the spam.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Search triage team: -> Future
Keywords: helpwanted
Target Milestone: mozilla0.9.9 → Future
Depends on: 171383
I'm working on this. Instead of displaying buttons I will have a drop-down menu.
Since it's my first hacking, please be very strict when reviewing.
Keywords: helpwantedpatch
I noticed two things when switching engines:

1) if there are a lot of engines, the CPU usage goes up like mad and the browser
freezes during some time. If there are really a lot, it crashes.

2) the images of the individual search pages don't always load (because of the
huge CPU usage?). Funnily, it also happens without the patch. For example, I've
repeatedly duplicated the bug that google's image didn't show.
Blocks: 171383
No longer depends on: 171383
Comment on attachment 101513 [details] [diff] [review]
Displays the engines in a drop-down menu instead of separate buttons

r=sgehani
Attachment #101513 - Flags: review+
I'm not sure, but the CPU usage could be the issue bug 172450 is about.
r=rjc  if you also add icons on the menu items, via adding the attribute:
    src="rdf:http://home.netscape.com/NC-rdf#Icon"
on the <menuitem> nodes.
Bug 172450 is non-related, BTW.
Comment on attachment 101800 [details] [diff] [review]
Patch v1.1 (with icons on dropdown and some correctly indented attributes)

r=sgehani
r=jrc
Attachment #101800 - Flags: review+
By the way, I didn't *remove* the icons, they have been removed quite some time
ago, and since I didn't know the reason of that change, I didn't change that
back. Now the icons are restored as per rjc's comment.
Hyatt, can you please sr this?
Comment on attachment 101800 [details] [diff] [review]
Patch v1.1 (with icons on dropdown and some correctly indented attributes)

Note that because of the bugzilla upgrade, it looks like I reviewed my own
patch. However, sgehani reviewed it in comment #15 and rjc in comment #17,
asking for a minor change, which I integrated into the patch.
Attachment #101800 - Flags: superreview?(hyatt)
Comment on attachment 101800 [details] [diff] [review]
Patch v1.1 (with icons on dropdown and some correctly indented attributes)

Asking bryner for sr (previously hyatt, but no answer)
Attachment #101800 - Flags: superreview?(hyatt) → superreview?(bryner)
Flags: blocking1.3a?
Flags: blocking1.3a?
Flags: blocking1.3a-
Flags: blocking1.3b?
Flags: blocking1.3b? → blocking1.3b-
Asa, What's the problem with this bug? why doesn't it get super-reviewed and why
don't you want it to be included in the next release?
Sorry Erich, but it's notoriously hard to get super-reviews for UI patches,
partly because most of the super-reviewers (including me) don't know much about
the UI side.

Try emailing jag. If that fails, send email to drivers again to remind us.
Erich, I didn't say I didn't want it included in the next release. blocking1.3b-
means that I wouldn't hold the next release for this bug. If we were all ready
to release and this patch wasn't landed I wouldn't stop the release. That being
said, there's no reason that this shouldn't make it into the tree sometime
before we release 1.3b (about 6 weeks). You don't need drivers to say they'd
hold a release in order to get a patch landed. 
Comment on attachment 101800 [details] [diff] [review]
Patch v1.1 (with icons on dropdown and some correctly indented attributes)

sr=jag
Attachment #101800 - Flags: superreview?(bryner) → superreview+
checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Verified fixed in build 2002123022
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: