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)
Tracking
(Not tracked)
VERIFIED
FIXED
Future
People
(Reporter: lynnw, Assigned: samir_bugzilla)
References
(Blocks 1 open bug)
Details
Attachments
(4 files, 1 obsolete file)
80.35 KB,
image/jpeg
|
Details | |
44.90 KB,
image/png
|
Details | |
2.32 KB,
patch
|
Erich.Iseli
:
review+
jag+mozilla
:
superreview+
|
Details | Diff | Splinter Review |
15.40 KB,
image/png
|
Details |
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.
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.
Comment 4•23 years ago
|
||
nav triage: this is not a beta stopper for Netscape.
Comment 5•23 years ago
|
||
I had the same pb with earlier version on Linux This bug seems to be fixed (0.9.2.1 Linux)
Comment 6•23 years ago
|
||
<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
Assignee | ||
Comment 7•23 years ago
|
||
Moving to mozilla0.9.7.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Assignee | ||
Comment 8•23 years ago
|
||
-> mozilla0.9.8
Assignee | ||
Comment 9•23 years ago
|
||
Really moving to mozilla0.9.8. Sorry for the spam.
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Assignee | ||
Comment 10•23 years ago
|
||
Search triage team: -> Future
Keywords: helpwanted
Target Milestone: mozilla0.9.9 → Future
Comment 11•22 years ago
|
||
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.
Comment 12•22 years ago
|
||
Updated•22 years ago
|
Keywords: helpwanted → patch
Comment 13•22 years ago
|
||
Comment 14•22 years ago
|
||
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.
Updated•22 years ago
|
Assignee | ||
Comment 15•22 years ago
|
||
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+
Comment 16•22 years ago
|
||
I'm not sure, but the CPU usage could be the issue bug 172450 is about.
Comment 17•22 years ago
|
||
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.
Comment 18•22 years ago
|
||
Bug 172450 is non-related, BTW.
Comment 19•22 years ago
|
||
Attachment #101513 -
Attachment is obsolete: true
Comment 20•22 years ago
|
||
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+
Comment 21•22 years ago
|
||
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.
Comment 22•22 years ago
|
||
Hyatt, can you please sr this?
Comment 23•22 years ago
|
||
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 24•22 years ago
|
||
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)
Updated•22 years ago
|
Flags: blocking1.3a?
Updated•22 years ago
|
Flags: blocking1.3a?
Updated•22 years ago
|
Flags: blocking1.3a-
Updated•22 years ago
|
Flags: blocking1.3b?
Updated•22 years ago
|
Flags: blocking1.3b? → blocking1.3b-
Comment 25•22 years ago
|
||
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.
Comment 27•22 years ago
|
||
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 28•22 years ago
|
||
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+
Comment 29•22 years ago
|
||
checked in
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•