Closed
Bug 33420
Opened 25 years ago
Closed 23 years ago
[RFE] Give sidebar a Close button (Make opening/closing more discoverable)
Categories
(SeaMonkey :: Sidebar, enhancement, P2)
SeaMonkey
Sidebar
Tracking
(Not tracked)
VERIFIED
FIXED
mozilla0.9.7
People
(Reporter: locka, Assigned: samir_bugzilla)
References
Details
(Whiteboard: [ready to checkin])
Attachments
(7 files, 2 obsolete files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
image/gif
|
Details | |
(deleted),
image/gif
|
Details | |
(deleted),
image/gif
|
Details | |
(deleted),
image/gif
|
Details | |
(deleted),
application/octet-stream
|
Details | |
(deleted),
patch
|
morse
:
review+
alecf
:
superreview+
|
Details | Diff | Splinter Review |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; N; WinNT4.0; en-US; m14)
BuildID: 2000032409
The sidebar should have a close button (e.g. an 'X') next to the existing
'customize...' button. Clicking on this would have the same affect as the
"View|Sidebar" menu option but would be more obvious.
Reproducible: Always
Steps to Reproduce:
none needed
Comment 1•25 years ago
|
||
more ideas for german, but who would ever want to close the sidebar? :-)
Assignee: slamm → german
Comment 2•25 years ago
|
||
Not a good idea. When (not if) the user hits the 'x' accidentally, he/she will
probably spend at least a minute trying to figure out how to get the toolbar
back. I'm sure you guys would do better with the interface here than Microsoft
did with Outlook Express (when you kill the oe sidebar, a non-control becomes
an "invisible" control to let you re-open it; view menu says nothing), but it
will still be confusing.
If the user wants to collapse the sidebar, they can. If the user wants to get
rid of the sidebar, they probably want to get rid of it permanently, so the
menus should work fine (a hint in "customize..." about how to turn it on and
off wouldn't hurt, though). If the user actually wants to get rid of the
sidebar and then bring it back, why confuse them by giving them an extra
control to turn it off that doesn't indicate how to turn it back on?
I disagree that an X will confuse users (well I would wouldn't I?). Most
users know what an X does, so the only issue is how to make sure they know
how to get the panel back. A one shot message box would take care of that,
informing them that they can turn the panel back on from the menu.
The point of having an X is that it's more convenient to use and a visual clue
that the sidepanel can be gotten rid of.
Comment 4•25 years ago
|
||
spam: changing qa contact on sidebar bugs from paulmac to shrir@netscape.com
(all 67 of them!)
QA Contact: paulmac → shrir
Duplicate of 32662? Although people seem to be paying more attention to this one.
Sure, add an X. Make it look even MORE like Windows :-).
Well, adding an X is one option (which doesnot work so well on Mac), but there
are alternative solutions.
We have found that opening the sidebar is also not very discoverable. So I'd
rather call this bug "Make open and closing the sidebar more discoverable", and
tackle the problem from this angle.
Also there is a difference between closing (what the grippy does) and completely
removing the sidebar (what the view menu currently does). This is somewhat
analogous to toolbar behaviour, but certainly hyas potential for confusion.
adding to summary of bug, nominating for beta 2.
Keywords: beta2
Summary: Put an 'X' on the sidebar → Put an 'X' on the sidebar [Make open and closing the sidebar more discoverable]
Updating to All for Platform/OS as this is a platform independent change to the
sidebar. Will have to be looked at on all platforms (possibly individually). But
like Paulmac said, "...who would ever want to close the sidebar? :-)"
OS: Windows NT → All
Hardware: PC → All
Comment 10•25 years ago
|
||
Even this early on, and in the n.p.m.ui group (which you'd expect to be filled
with fairly advanced users), there is still the occasional person wondering how
to close the sidebar. A Close button for the sidebar would solve this problem.
And I agree with Adam: just pop up a message the first time the user ever closes
the sidebar, telling them that they can open it again from the View menu.
Resummarizing because an `X' is only appropriate on Windows. Adding 4xp, as IE
versions 4 and higher have an `X' button on their sidebars. Adding pp, because
while this needs to be implemented for all platforms, it needs a different XUL
overlay and graphic for each one (an `X' on the right for Windows, a square on
the left for MacOS/Unix/BeOS, etc).
Comment 11•25 years ago
|
||
If they can't figure out how to close the sidebar, they're definately not going
to be able to figure out how to get it back if they click close accidentally.
I'm assuming there will be an alert telling users how to turn it back on,
coupled with "Show this message next time" (or "Don't show this message next
time"), when they click the close button.
Comment 12•25 years ago
|
||
Interesting comparison: my friend accidentally clicked the grippy for the
navigation toolbar in netscape 4.7. Naturally it rotated to its "closed"
position and hid the toolbar. He came to ask me how to get the toolbar back,
and didn't even know what he'd done to make the toolbar disappear. Once I told
him to click on the grip he got it back easily. Perhaps if a dialog had popped
up showing a little picture of what he had done he would have been able to grasp
the concept immediately.
As for "View/Sidebar," I've found that users don't know what the "view" menu is
for. If users knew, then they would look there, right?
Comment 14•25 years ago
|
||
Putting on [nsbeta2+][5/16] radar. This is a feature MUST complete work by
05/16 or we may pull this feature for PR2.
Whiteboard: [nsbeta2+][5/16]
Comment 15•25 years ago
|
||
welp...5/16 has come and gone with no comment and no change on this bug.
Removing nsbeta2+ designation for reconsideration or new timeframe (in
comparison with the other larger, feature/crasher bugs, is this enhancement
really a beta2 necessity?)
Keywords: polish
Whiteboard: [nsbeta2+][5/16]
Comment 17•25 years ago
|
||
In addition to a close button, we might also want an open button to make this
more discoverable. Lake is doing some usability tests to see if we need the
make opening and closing more discoverable.
nominating nsbeta3
Keywords: nsbeta3
Comment 18•24 years ago
|
||
that not bad idea they should add a closing button on the sidebar menu
Comment 19•24 years ago
|
||
*** Bug 46171 has been marked as a duplicate of this bug. ***
Comment 20•24 years ago
|
||
Alfredo, what do you mean by sidebar menu, there is no menu there as far as I can
tell.
As far as an open close mechanism, we have talked about a button being next to
the bottom part of the right edge of the sidebar frame, sort of like a handle
reaching into the status bar. The problem right now seems to be implementation
across themes.
Also some newer usability data points indicate that opening/closing is not such a
big problem as originally feared. Also, making the grippy clearer will help solve
this bug (see bug 30595)
Status: NEW → ASSIGNED
Comment 21•24 years ago
|
||
for my two cents I think the real concentration should be on making the grippy more obvious. Looking at the classic skin the
sidebar grippy really looks 'grippy' and indicates that something useful might happen if you were to click/drag it. We should try
something similar for the modern skin.
If you go with the close box(X) it won't be long before someone wants the minimize button(—)(the horror!). Plus a box on the left
for the mac is gauranteed to look dumb. Also, adding the (X) is akin to saying the sidebar is a window and then I would expect
the way to open it would be File-->New-->Sidebar. Which I think would be horrible too.
I think the grippy is a great idea and clicking the same widget to open/close is much better IMHO. So can't we just make it better?
Comment 22•24 years ago
|
||
See also bug# 31684 (a duplicate, I think.)
As I wrote there, the best I've come up with for this problem (pretty much in
order of goodness): adding a "Close sidebar" option to the sidebar menu (Tabs
right now), making the "Tabs" menubutton not right-margin-bound, or always
putting the close button on the left.
Comment 23•24 years ago
|
||
sidebar triage team:
nsbeta3-
We think improvements in the grippy will make this more discoverable.
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3-]
Comment 24•24 years ago
|
||
So..should this bug be closed as wontfix or do we plan to implement this in the
future? Thx!
Comment 25•24 years ago
|
||
What kind of grippy improvements?
Comment 26•24 years ago
|
||
*** Bug 31684 has been marked as a duplicate of this bug. ***
Comment 27•24 years ago
|
||
Discussion of the grippy is irrelevant, as the grippy can not be used to close
the sidebar -- only to collapse it. Scaremongering about the need for an `Open'
button or a `Minimize' button is similarly misguided -- neither of these is
necessary, the need here is for a means of *closing* the sidebar which is more
obvious than an item in the `View' menu.
Windows:
+-------------------------+
|My Sidebar [Tabs v] [X]|
+-------------------------+
Mac OS:
+-------------------------+
|[_] My Sidebar [Tabs v]|
+-------------------------+
Other platforms:
+-------------------------+
|[X] My Sidebar [Tabs v]|
+-------------------------+
Comment 28•24 years ago
|
||
Mat: The grippy dicussion is relevant to this bug. people use terms 'close' and
'collapse' interchangeably in this bug as well as users that we had we looked at
in the usability lab. The menu action in the 'View' menu is often referred to by
users as 'completely hiding' or 'removing' the sidebar. Most users care about
the former, wanting to make room for content temporarily.
Some grippy issues are currently being addressed:
- Modern skin grippy is in process of being updated (already has happened in the
latest builds) to make more visible and better indicate motion direction.
- Classic grippy worked pretty well in 4.x no changes planned here.
Based on what we have seen and how the sidebar is used* we decided that a close
button does not make sense in this context as in this design we do not have a
counterpart in a similar position that would re-open it.
*) The sidebar is used differently than say the left area in IE5. Most sidebar
tabs are used in parallel for monitoring information (ie buddy list, stock
ticker, CNN news) that updates while most of the IE5 functionality in this area
is used for short-term intermittent tasks.
Comment 29•24 years ago
|
||
the mechanism used to open the IE "Search,Favorites and history" would be fine
for mozilla too. it does not matter whether you want to monitor quotes the
whole time or just access a single quote temporarly
opening AND closing the sidebar with one click would be fine anyway
Comment 30•24 years ago
|
||
From what I have seen in the lab and outside the current design with a clickable
grippy seems to be working pretty well for btoh modern and classic. Marking wontfix.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WONTFIX
Comment 31•24 years ago
|
||
The rest of us don't have access to your usability lab of wonder. Reopening
this for further explanation, because I often find myself going to close the
sidebar at the click of a button (as in IE), but I can't. Yes, close -- not
not collapse. I think this is especially important considering the sidebar
opens and shows itself (to show search results) if you're searching at a site
and you have the right pref on, since most people would want to completely
close it again when they're done navigating the results (that's the state it
was in before they searched). Of course, most people don't want it to open in
the first place, but there's another bug on that.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Comment 32•24 years ago
|
||
http://www.macfixit.com/ultimate/Forum21/HTML/000032-2.html:
"Took me awhile to figure out how to hide that annoying side bar....they didn't
make that "button" on the edge very obvious...so they obviously want you to
keep it open."
Reassigning to me. UI discussion about this is fine and welcome, but I don't
think this needs to be assigned to someone who isn't going to fix it.
Assignee: german → blakeross
Status: REOPENED → NEW
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M18 → mozilla1.0
Comment 33•24 years ago
|
||
Wow, there's a lot of discussion on a bug that's, to me, really straight-forward
and obvious. Adding Matt's implementation along with the one-time message
suggested by Adam won't harm the interface at all, and from the sounds of it at
least a few people will be less confused. I'm all for it.
Updated•24 years ago
|
Comment 34•24 years ago
|
||
Possibly a dialog comes up when the user hits the X? Since you've determined
that the view menu is not discoverable, tell them that's where this lives, so
they can reopen it. Something like, 'This will completely remove the sidebar
from all windows, are you sure you want to do this? To reopen the sidebar, go
to view > My sidebar', as well as an option to kill the dialog on following
closes.
Comment 35•24 years ago
|
||
I've changed my mind about that. A dialog shouldn't come up for something as
trivial as a windowing operation (which is basically what this is), unless the
user is risking data loss (e.g. `Save changes to foobar.html?'). For a dialog to
come up when I close the sidebar would be quite annoying, even if it only
happened once.
Comment 36•24 years ago
|
||
I'm with kerz. Having the sidebar disappear, and not being able to figure out
how to get it back quickly, is more annoying than seeing a dialog the first
time you try to get rid of it.
Nominating for mozilla0.9. I think I've seen some NS 6.0 reviewers complaining
about the sidebar, so having an obvious way to get rid of it would be good.
Keywords: mozilla0.9
Updated•24 years ago
|
Comment 38•24 years ago
|
||
I think the attached patch should at least get us started here. It places an X
button at the right edge of the sidebar header and clicking on it is equivalent
to selecting View|Sidebar. No warning menu for now, because I don't know how to
save the state to remember whether it's been shown or not (I'm just learning
this stuff, so any comments or pointers will be welcomed). Also, I wasn't sure
which one of MANIFEST and makefile.win had to be modified in addition to jar.mn
to add the X gif to the right place, so I changed both of them.
X gif should go to mozilla/themes/classic/communicator/sidebar/win/sidebar-x.gif
You might notice that the button is not square when the mouse goes over it. I
couldn't figure out how to do it without hard-coding 'width' in sidebar.css.
Could anybody tell me if there is a way?
Comment 39•24 years ago
|
||
Comment 40•24 years ago
|
||
Comment 41•24 years ago
|
||
Davor, thanks for the patch. However, we need platform-specific overlays so
that we can position the button as necessary (read earlier comments in the bug).
Updated•24 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 42•23 years ago
|
||
David, are you up for the task of platform-specific overlays?
Priority: P1 → P3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 43•23 years ago
|
||
We received lots of feedback about this from 6.1PR1. Most users can't figure
out how to hide *or* close the sidebar, and are annoyed at the screen real
estate it's using. We should do this for .9.2.
Priority: P3 → P1
Target Milestone: mozilla0.9.3 → mozilla0.9.2
Comment 44•23 years ago
|
||
"We received lots of feedback about this from 6.1PR1" when, yesterday? We just
shipped that bad boy.:-)
for my .02 I still think this is a Bad Idea. If there was poor feedback from the
6 release I would imagine it had more to do with the slider not being distinct
enough in the modern skin (like german has been saying). If indeed blake is
privy to instantaneous feedback then, I've got nothing to counter that - but i
still think it's clugey.
Comment 45•23 years ago
|
||
Sure, there's lots of feedback already...
Actually, though, I think now that most of the comments (about closing the
sidebar) were complaints about bug 85026. Still, some people expressed
uncertainty at how to hide it at all.
Priority: P1 → P3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 46•23 years ago
|
||
Food for thought in passing... What about adding a Sidebar icon (with an
Open/Close state/functionality) as the first item on the left-edge of the
taskbar, just before the Nav icon?!
Comment 47•23 years ago
|
||
As a state widget? ie depressed when it's showing? we could also borrow
microsoft's pushpin image ...
Comment 48•23 years ago
|
||
Comment 49•23 years ago
|
||
I actually just came across a user who submitted feedback requesting the same
thing rbs is:
"Dragging the sidebar with the mouse in and out a
cumbersome (either for bookmark, search, etc). I
would suggest to add additional button to the
taskbar on the bottom left, next to "navigator,
"mail" applets, which with one mouse click quickly
drags (pops) the My sidebar on the screen. Or you
might allow a right click on the mouse to pop the
mysidebar instead of adding applet "
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla1.0
Comment 50•23 years ago
|
||
Sorry for being quiet for so long, school and other work demanded my full
attention. I'm still not clear why the close button has to be platform-specific.
Do you want to have the close box (not X) for MacOS because this kind of panel
already exist in its UI guidelines? I thought this was a non-standard UI
element, and it's not actually a window that we have to emulate each platform's
window decorations. (IE 5 on MacOS uses a sort of vertical tabbed folders for
this, which is totally different from the Windows version, but interestingly
enough it doesn't use the close box either.)
Comment 52•23 years ago
|
||
Comment 53•23 years ago
|
||
Comment 54•23 years ago
|
||
Once closed, one has to go back to the menu to re-open it, right?
It seems more appealling to me to have a button on the taskbar to quickly toggle
on/off the sidebar. There are buttons (like IM) that have established their own
distinctive trademark. An eye-catching representative button for the sidebar
could be invented as well.
Comment 55•23 years ago
|
||
rbs: F9
Comment 56•23 years ago
|
||
rbs: that's the subject of another bug (i don't remember the number)
Comment 57•23 years ago
|
||
Looks like this one has fallen on deaf ears. No action in weeks. This is not a
stop-ship IMHO. Propose we move it out to a later milestone.
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Comment 58•23 years ago
|
||
jaime, I understand this is not a stop-ship but let's please now do whatever has
to be done to prioritize it for the next subsequent release. This issue has
always been high on the annoyance list in every forum for feedback, in every
release to date. As we fix everything else this will be the issue that climbs to
the top - not devastating but highly visible.
Looking at the comparisons to IE and Opera I think we have a superior
'click-on-the-fly' ability that they lack. For people who actually use the
sidebar it's very convenient to oneclick it away and back as necessary whilst
mousing around. if you don't use it often, then turn it off in the menu and it
doesn't matter whether there is a grippy or an xbox or whatever.
Comment 59•23 years ago
|
||
It hasn't gotten lost in the shuffle, I've had a patch to add an X for weeks,
unfortunately it was created right before leaving Netscape and has gotten lost
in the shuffle. It's on an external hard drive of mine, though.
Comment 60•23 years ago
|
||
Mass moving lower-priority bugs to 0.9.6 (with Blake's pre-consent) to make room
for remaining 0.9.4/eMojo bugs and MachV planning, performance and feature work.
If anyone disagrees with the new target, please let me know.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.5
Comment 61•23 years ago
|
||
Perhaps the most sensible thing to do in the short term is add a "Hide Sidebar"
to the popup menu that appears when you click on the "Tabs" button. This would
be trival to implement.
Comment 63•23 years ago
|
||
A post in bug 41445 gives the upcoming plan for the context menu.
Perhaps, adamlock's proposal can be considered over there.
Comment 64•23 years ago
|
||
Well, I did have a patch for this but apparently samir does now as well.
Assignee: blakeross → sgehani
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.6 → ---
Assignee | ||
Updated•23 years ago
|
Priority: P3 → P2
Target Milestone: --- → mozilla0.9.6
Assignee | ||
Comment 65•23 years ago
|
||
Assignee | ||
Comment 66•23 years ago
|
||
pchen, please r.
blake, please sr.
Comment 67•23 years ago
|
||
This looks too complex...I didn't need to specify all that css styling and have
more than one image. I'll dig up my patch.
Assignee | ||
Comment 68•23 years ago
|
||
Well, I can see this being done with an <image/> (only one .gif needed) but that
doesn't really visually indicate the various states the user is in. I would
treat the close button the same as any button; the same as the 'Tabs' button on
the sidebar header which has various states.
You may have got this working with the patch you are describing but I contend
that we really need to capture at least three states: normal, hover,
hover+active via different images. And this is achieved via the styling I have
used.
I can see how one could argue against the need for a distinct hover state image;
in fact, classic doesn't use a distinct image: it's only modern that does so
that it mimics the nav toolbar buttons and looks part of the skin.
CC'ing Marlon and Ben for input.
Comment 69•23 years ago
|
||
My patch had all the hover states etc...but the toolbarbutton took care of all
of it. I simply had to have a rule specifying the image. But I hadn't done
Modern yet, and I'm not familiar with modern's structure, so I guess it might be
necessary to have separate images for that...
Assignee | ||
Comment 70•23 years ago
|
||
OK, I understand why you were surprised by this patch then. Note that I am
still to receive image(s) from gail for classic. As of now I have just tossed
in the windows close button images which is a stop-gap measure. I see how you
could have captured the states with the different style rules that
<toolbarbutton/> specifies but don't think they will look like native buttons in
classic. As I understand it, the point of classic is to make the widgets look
like native ones, not our own manifestation.
And as far as modern goes, it sounds like you are open to images for different
states and hence you are open to reviewing my patch. If you'd like I can attach
the images marlon has supplied.
If there are outstanding objections please let me know and I'll address them.
Thanks.
Status: NEW → ASSIGNED
Comment 71•23 years ago
|
||
The button I added for Classic had exactly the same styling as the Tabs button
that it is next to, and it looked good. I used an X that Asa sent to me. Sure,
I'll review this soon.
Comment 72•23 years ago
|
||
I like Blake's idea. It seems much easier and more flexible. If, for some
reason, we ever change the look of <toolbarbutton>, this button changes
automatically.
Assignee | ||
Comment 73•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Summary: Give sidebar a Close button (Make opening/closing more discoverable) → [RFE] Give sidebar a Close button (Make opening/closing more discoverable)
Assignee | ||
Comment 74•23 years ago
|
||
Plan on landing early in mozilla0.9.7.
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Comment 75•23 years ago
|
||
*** Bug 109495 has been marked as a duplicate of this bug. ***
Comment 76•23 years ago
|
||
The patch looks wrong. The close button should be the first item in the sidebar
header, not the last -- so that you can use {float: right} or similar to put it
on the right end in Windows Classic, and {float: left} or similar to put it on
the left end in Mac Classic.
Assignee | ||
Comment 77•23 years ago
|
||
Can't use {float: right;} now since we are blocked by bug 113658.
Assignee | ||
Comment 78•23 years ago
|
||
Filed bug 113725 regarding the need for mac and windows classic close button
icons. Hooked this up to the navigator teams external dependency tracker: bug
112941.
Assignee | ||
Updated•23 years ago
|
Attachment #54986 -
Attachment is obsolete: true
Assignee | ||
Comment 79•23 years ago
|
||
Assignee | ||
Comment 80•23 years ago
|
||
morse, please r.
alecf, please sr.
Comment 81•23 years ago
|
||
Oh please, no tooltip on the close button!
Comment 82•23 years ago
|
||
Comment on attachment 60574 [details] [diff] [review]
Patch rev 2: leaner CSS rules and tooltip for close button.
r=morse
Attachment #60574 -
Flags: review+
Comment 83•23 years ago
|
||
> Oh please, no tooltip on the close button!
Why not? Windows Close buttons have tooltips (since 95, I think) and if it
stops people confusing it with some sort of remove tab button then I think it's
fine. Though perhaps text more along the lines of 'Close Sidebar' would be
better.
Comment 84•23 years ago
|
||
Comment on attachment 60574 [details] [diff] [review]
Patch rev 2: leaner CSS rules and tooltip for close button.
Is there any way we can share the close-sidebar button's CSS with the close-tab
button's CSS? that would make it easier for CSS designers to style the close
buttons.
Assignee | ||
Comment 85•23 years ago
|
||
Alec,
When I first did this work Hyatt mentioned that he had plans to remove the close
tabs button. Actually, the images for this modern close button were done for
the close tabs button. At this point, I'd like to get my patch in and leave the
burden of factoring out the close button to a generic place up to the tabs folks.
Comment 86•23 years ago
|
||
Actually I'm not going to remove the close button, and we should share the same
one. You should move the images over into global.
Comment 87•23 years ago
|
||
* How about oncommand instead of onclick:
+ <toolbarbutton id="sidebar-close-button" onclick="SidebarShowHide();"
* I agree with Hyatt, these close icons are pretty enough that we could use
them for tabbrowser. Could you just move the images into
themes/modern/global/icons and themes/classic/global respectively?
* Could you check in the disabled icon that marlon made? We could use it for the
tabs close button.
Assignee | ||
Comment 88•23 years ago
|
||
(*) Moved images and CSS to <theme>/global.
(*) Added the disabled close gif for modern.
(*) Changed onclick to oncommand.
I'd really like to get this in for mozilla0.9.7 so we can start getting
usability feedback on this.
morse, mind reviewing again?
alecf, please sr.
Thanks.
Attachment #60574 -
Attachment is obsolete: true
Comment 89•23 years ago
|
||
Comment on attachment 61165 [details] [diff] [review]
Patch rev 3 addressing reviewer comments.
r=morse
Attachment #61165 -
Flags: review+
Comment 90•23 years ago
|
||
Comment on attachment 61165 [details] [diff] [review]
Patch rev 3 addressing reviewer comments.
Ok, this looks alright to me. sr=alecf, but I welcome hewitt or another UI guy
to have the final say
Attachment #61165 -
Flags: superreview+
Comment 91•23 years ago
|
||
*** Bug 114568 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 92•23 years ago
|
||
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 23 years ago
Resolution: --- → FIXED
Comment 93•23 years ago
|
||
Did this cause the creep in startup time from 6.27 -> 6.31 Can you check.
Reopening bug to make sure this doesn't get lost.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 94•23 years ago
|
||
I think it is ok if the creep is post window open and doesn't delay window open.
Comment 95•23 years ago
|
||
Heh, first I was going to say "this is just because that test started reporting
the median of the window open times, instead of the average". But then I looked
at the raw numbers in the log, and the minimum went up. But then I looked at
law's checkin (which I missed earlier) and it now adds a little unnecessary
work to interval that we measure [should grab the time just before the
window.open() call is made, and don't do anything in between]. So, I don't
think window open times truly went up, but it would be a useful tweak to avoid
measuring anything that is not actually part of the window opening time.
Comment 96•23 years ago
|
||
> Heh, first I was going to say "this is just because that test started
> reporting the median of the window open times, instead of the average".
Em, "reporting the median ... instead of the _minimum_"
Comment 97•23 years ago
|
||
jrgm, I was looking at startup time. Measurement of that is independent of these
window open hooks.
Assignee | ||
Comment 98•23 years ago
|
||
danm file dbug 114797 for me to check the effect of my checkin.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 99•23 years ago
|
||
The "x"checxkbox to close the sidebar is the worst innovation yet. I tried it on
the Dec 13 nightly not knowing what it was for and lost the sidebar. I went to
the view menu and restored it, but upon opening an new windoe it was gone. It
also caused the ULR bar to disappear. This feature needs more work and
rethinking. At a min. there needs to be some text next to the checkbox such as
"close sidebar." The omnly way I could restore the sidebar when a new window
opened was to launch 0.96 and reset it.
Unless this feature is fixed so that it doesn't cause all subsequent new windows
to open without the sidebar (no tweaking of prefences can reset new windows with
the sidebar) IMHO this feature MUST be removed from the next milestone 0.97.
I am using Mac OS 8.6.
Comment 100•23 years ago
|
||
Paul, if this widget closes the sidebar, then it is working. I'm not seeing the
other defects you mention, but if you still encounter them in recent builds,
please file new bug reports.
Comment 101•23 years ago
|
||
"X" does indeed close the sidebar using 2/4 build.
marking verified.
If there are other bugs, please file them separately.
Status: RESOLVED → VERIFIED
Comment 102•23 years ago
|
||
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•