Bug Hunting Session
Bug 36571 - Find bar does not appear properly at top of screen
Summary: Find bar does not appear properly at top of screen
Status: CLOSED DUPLICATE of bug 36684
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
3.4.0 Beta2
Hardware: Other All
: medium critical
Assignee: Noel Power
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-04-25 02:54 UTC by Ed
Modified: 2011-05-13 09:02 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ed 2011-04-25 02:54:32 UTC
In 3.4 Beta 2 the "Find" toolbar does not appear properly if it was docked at the top of the screen with another toolbar docked below it before it was last closed.

Steps to reproduce:
1.  Open the "Find" toolbar, such as by pressing Ctrl+F;
2.  Dock the bar at the top edge of the screen, making sure another toolobar is also docked to the top edge and is below the "Find" bar;
3.  Close the "Find" toolbar either with Escape or via the context menu;
4.  Press Ctrl+F

Now View>Toolbars>Find is checked but no toolbar is visible.  The toolbar then appears when any toolbar docked to the top is moved, or the document is closed and the component restarted.

This does not happen if the Find toolbar is in the bottom row of toolbars docked to the top edge.
Comment 1 Zack 2011-04-27 16:04:31 UTC
Confirmed.
Comment 2 Don't use this account, use tml@iki.fi 2011-04-28 01:31:55 UTC
Zack, you are doing a great job in triaging bug reports and resolving them as duplicates etc, but please, no need to add otherwise uninformative "confirmation" comments. It just increases the mail load on developers. If there is no earlier comment that people explicitly would *not* be able to reproduce a bug, there is no need to add a comment if you *can* reproduce it. We should believe the bug reporter.
Comment 3 Zack 2011-04-28 06:43:29 UTC
(In reply to comment #2)
> Zack, you are doing a great job in triaging bug reports and resolving them as
> duplicates etc, but please, no need to add otherwise uninformative
> "confirmation" comments. It just increases the mail load on developers. If
> there is no earlier comment that people explicitly would *not* be able to
> reproduce a bug, there is no need to add a comment if you *can* reproduce it.
> We should believe the bug reporter.

Will do!  I'm still trying to get a hang of this whole triaging thing as it's really the only thing I'm capable of lol.  I read up on Bug Triaging on the wiki but the information is rather sparse.  Thanks for letting me know what I'm doing wrong, it's the only way I can learn!
Comment 4 Rainer Bielefeld Retired 2011-04-30 10:47:12 UTC
[Reproducible] with "LibreOffice 3.4Beta3  – WIN7  Home Premium  (64bit) German UI [DEV300m103 (Build:3)]" in CALC and WRITER, DRAW, others not tested. 

@Tor:
I disagree. We have lots of NEW bug reports what are DUPs, can't be reproduced, are related to localization, installed Extensions or other particular circumstances not mentioned in the report, are complete nonsense, ... . 

Because of that it's necessary to try whether it's possible to reproduce. But if nobody leaves it's comment that he was able to reproduce, hundreds might also try to reproduce, keep silence, and the next will try ... . That would be a terrible waste of time.

So Zack and others, please leave a comment if you have been able to reproduce, so that other QA staff knows whether further investigation will be required or whether time resources can be invested into confirmation of an other bug.

May be we will discuss this issue during the QA meeting in June.

But a simple "Confirmed" indeed is not very useful additional information. If possible and/or necessary you should try to add additional information, at least with what OS and LibO version confirmation has been successful.

I wonder whether this problem is related to the ones I reported with
"Bug 36684 - UI: Menu 'View> Toolbars' relations to toolbars messed up"

@Ed, @Zack:
What OS did you test? I believe it's independent, but you never know ...
Can you confirm Bug 36684?

@Zack:
If you believe that information in the wiki is too rare (and as a newcomer you might have a distinct ability to judge) you should add suggestions how to improve information on the Discussion pages.
Comment 5 Ed 2011-04-30 15:10:18 UTC
I found this issue on Windows 7.
Comment 6 Rainer Bielefeld Retired 2011-04-30 23:28:33 UTC
This one might be related to
Bug 36569 - Find toolbar unusable after undocking
Comment 7 Rainer Bielefeld Retired 2011-05-01 01:24:51 UTC
This one is a DUP of "Bug 36684 - UI: Menu 'View> Toolbars' relations to toolbars messed up". Because find Toolbar will be hidden / shown much more often than other ones the effect is much more visible than the ones from Bug 36684. Currently I prefer to leave both bugs open because there is much different information collected in the different reports and comments, and because Bug 36684 still is unconfirmed.

Tor:
I saw you active in some UI bugs - your area?
Please feel free to reassign if not!
Comment 8 Don't use this account, use tml@iki.fi 2011-05-01 12:26:03 UTC
Nah, I don't really feel particularly qualified to handle this.
Comment 9 Michael Meeks 2011-05-03 01:56:39 UTC
Kendy would be better - having done the toolbar work. I think we just don't want the "find" toolbar to be un-dock-able and move-able about, it makes little sense with the new (much cleaner) firefox style auto-apperance / hiding.
Comment 10 Rainer Bielefeld Retired 2011-05-05 23:14:22 UTC
*** Bug 36705 has been marked as a duplicate of this bug. ***
Comment 11 Michael Meeks 2011-05-09 13:55:34 UTC
Noel - Kendy asked me to ask you to take a look at this - is that ok ? :-)
Comment 12 Noel Power 2011-05-13 08:06:29 UTC
marking as a duplicate, I'm pretty certain it is, 36684 has more generic information

*** This bug has been marked as a duplicate of bug 36684 ***
Comment 13 Rainer Bielefeld Retired 2011-05-13 09:02:33 UTC
DUP is enough, no additional blocking.

Also remove from "Blocks Bug 35673", because Bug 35673 already blocks Bug 35673

I read good news concerning progress in Bug 35673 :-)