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.
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.
(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!
[Reproducible] with "LibreOffice 3.4Beta3 – WIN7 Home Premium (64bit) German UI [DEV300m103 (Build:3)]" in CALC and WRITER, DRAW, others not tested.
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"
What OS did you test? I believe it's independent, but you never know ...
Can you confirm Bug 36684?
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.
I found this issue on Windows 7.
This one might be related to
Bug 36569 - Find toolbar unusable after undocking
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.
I saw you active in some UI bugs - your area?
Please feel free to reassign if not!
Nah, I don't really feel particularly qualified to handle this.
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.
*** Bug 36705 has been marked as a duplicate of this bug. ***
Noel - Kendy asked me to ask you to take a look at this - is that ok ? :-)
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 ***
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 :-)