310776 - Chevron doesn't appear on Personal Toolbar in new navigation windows after clicking hyperlinks

Status: RESOLVED DUPLICATE of bug 338803

(SeaMonkey :: Bookmarks & History, defect)

Description

[VinDSL]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050929 SeaMonkey/1.1a
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050929 SeaMonkey/1.1a

When you start a fresh instance of SeaMonkey in Windows 2000 Pro, there is a
chevron/button on the right-side of the Personal Toolbar that expands the list
of personal links that won't fit inside the default screen. This is normal
behaviour.

However, if you click a hyperlink on a web page, and SeaMonkey opens a new
navigation window, there is NO chevron/button in the new window to expand the
personal links list. The personal links simply scroll past the right-side of the
screen on the Personal Toolbar, beyond view, with no way of getting at these
links except through the Bookmarks menu.

Reproducible: Always

Steps to Reproduce:
1.Start SeaMonkey from your desktop.
2.Got to any web site and click any hyperlink that opens a new navigation window.

Actual Results:  
The original window, that was started from the desktop, will have a
chevron/button on the Personal Toolbar.  The new navigation window will not have
a chevron/button on the Personal Toolbar.

Expected Results:  
The chevron/button should always appear on all instances of SeaMonkey, not just
navigation windows that are opened from the desktop.

Comment 1

[VinDSL]

Attachment: Screenshots of navigation windows with & without chevron/button.

Comment 2

[zug_treno]

Reproducible with SeaMonkey/20051002/1.1a and SeaMonkey/20050929/1.0b, only
sometimes reproducible with SeaMonkey 1.0a.

Comment 3

[Dan Mellem]

Confirmed with 2005100305 as well with Windows XP. This also occurs when
middle-clicking to open in a new window.

One workaround is to force new windows to open in the same window (under Tabbed
Browsing), though this doesn't fix everything.

Changing the window size doesn't lose the chevron unlike bug 309471, and there
was no warning message, unlike bug 214007. I can't find anything else similar
for SeaMonkey so confirming.

Comment 4

[VinDSL]

The situation is getting better.  I installed the latest trunk a few minutes ago
(20051004 SeaMonkey/1.1a) and I can now make the Chevron/button appear by
resizing the new navigation window.  Also, the Chevron/button sometimes appears
by itself in the new navigation window, maybe 25% of the time.  So, progress is
being made!

Comment 5

[VinDSL]

I had to switch back to a tenderbox build of SeaMonkey 1.1a.  The trunk build I
used last night has simply too broken to use.  Some JavaScript proggies were not
working for me, some extensions quit working also, yada, yada.  Personally, I
have found the tenderbox/CREATURE builds to work the best for me, so that's what
I'm using again.

http://ftp.mozilla.org/pub/mozilla.org/seamonkey/tinderbox-builds/CREATURE/

That made me think, "It sure would be nice if we were all on the same page!"

However, there is no mechanism (that I can see) in Bugzilla to accomplish this.
 For instance, this is listed as a Bookmark problem in the Mozilla Application
Suite, which isn't necessarily the case.

While I appreciate the confirmations, for all I know, you 'guys' are (most
likely) running a different build than I am.  So, for the remainder of this bug
report, I think 'we' should state which build 'we' are using, yes?

At present, I am using the tenderbox/CREATURE build: Mozilla/5.0 (Windows; U;
Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051005 SeaMonkey/1.1a

Comment #4 (above) applies to this build as well...

Comment 6

[Dan Mellem]

With build 2005101105, the chevron didn't show up until I resized the window, in
which case it DID show up. However, new windows now work correctly.

Comment 7

[Dan Mellem]

Well, now with a reboot, it is sometimes working when opening in a new window,
and sometimes not. Middle-clicking on a bookmark also resulted in a window
without the chevron. However, it's inconsistent and "restoring" and "maximizing"
does bring it back.

Comment 8

[Hermann Schwab]

(In reply to comment #3)
 
> Changing the window size doesn't lose the chevron unlike bug 309471, and there
> was no warning message, unlike bug 214007. 

Bug 309471 was duped to Bug 214007, and bug 214007 comment 15 has 3 steps to demonstrate the bug without warning.

Comment 9

[Ray Booysen]

Reassigning as per Bug #32644

Comment 10

[Isaac]

SeaMonkey 1.5a
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051219 SeaMonkey/1.0b Mnenhy/0.7.2.0

I tried the latest nightly build (2006032608) and I'm not able to see the chevrons to get to the bookmarks not shown even from the first instance/initial startup.  

Resizing the window does not resolve the issue.  

Comment 11

[Tony Madaj]

SeaMonkey 1.5a

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060327 SeaMonkey/1.5a

Still not see seeing the chevrons.  Maximizing or resizing SeaMonkey does not help , but moving a bookmark on the Personal Toolbar does cause the chevrons to appear.

Comment 12

[Uldis Bojars]

> Still not see seeing the chevrons.  Maximizing or resizing SeaMonkey does not
> help , but moving a bookmark on the Personal Toolbar does cause the chevrons to
> appear.

Can confirm the same behaviour in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060412 SeaMonkey/1.5a {Build ID: 2006041208}

No chevron when Seamonkey starts up and it does not appear if resizing / maximizing. [ If that matters, the personal toolbar was longer than the screen width already in Mozilla Suite profile, which then got used by Seamonkey ]

Inserting a new bookmark into the toolbar causes the chevron to appear.

Comment 13

[Xavier Vincent]

Still happens in SeaMonkey 1.0.1 - Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.8.0.2) Gecko/20060404 SeaMonkey/1.0.1.

Comment 14

[[e-mail]]

This bug appears to have been caused by a core resize event regression. I see no sign of that regression getting fixed on the 1.8.1 branch for SM1.1 and it stands no chance of getting fixed for SM1.0.x

On the trunk (for SM1.5) things are different; the event rewrite may have resolved the bug by changing the way resize events work. However the resize code has not been updated to match the new events.

Comment 15

[Xavier Vincent]

This seems to be identical to <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=338803">Bug #338803</a> which was fixed in SeaMonkey 1.04 (rv:1.8.0.6). This one should be marked as "FIXED" too. 

Comment 16

[Philip Chee]

WFM Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.2pre) Gecko/20110420 Firefox/4.0.2pre SeaMonkey/2.1pre