Samuel Sidler (old account; do not CC) Reporter
	Description • 19 years ago

This is filed with the 8/12 FF nightly on Windows.

When switching tabs from a secure site which has an RSS feed to one that is not
secure and does not have an RSS feed, there is major redraw in the location bar
where the icons are. You can see them quickly drop off to the left instead of
just disappearing as they do when there is only one icon in the location bar.

This is reproducable about 75% of the time depending on how quickly you switch
tabs (and how quick your eye is).

	Samuel Sidler (old account; do not CC) Reporter
	Comment 1 • 19 years ago

s/left/right (they drop off to the right)

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 2 • 19 years ago

I am seeing this on Mac, too, using the Aug 16 2005 build. There is also a fun
redraw that happens when you go from an insecure site with RSS feed to a secure
site without RSS feed:

1. load any old weblog
2. in a new tab, load some secure site that has no rss
3. switch from insecure-RSS to secure-no-RSS

When I do this, I clearly see the lock icon appear, bumping the rss one to the
left, and then the rss one disappears.

	Mike Beltzner [:beltzner, not reading bugmail]
	Comment 3 • 19 years ago

Removing blocking status on the feedview bug since that's been backed out. This
still happens with the latest nightlies, though ...

	Peter
	Comment 4 • 18 years ago

I can see this bug.
Site with no icon in location bar - normal behaviour.
Secure site, site with rss feed, secure site with rss feed - major redraw in the location bar.

FF 2.0b1

	Phil Ringnalda (:philor)
	Comment 5 • 18 years ago

*** Bug 352612 has been marked as a duplicate of this bug. ***

	Robert Sayre Assignee
	Comment 6 • 18 years ago

still happens.

	Robert Sayre Assignee
	Comment 7 • 18 years ago

still happens.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 11 • 18 years ago

Comment on attachment 248110 [details] [diff] [review]
hide / unhide the feed button when security context switches

I had a hard time reproducing this bug consistently. Is my computer too fast? Is it worse for Macs?

>Index: browser.js

>+  _updateSecurityUI : function(level, label)
>+  {
>+    this.securityButton.setAttribute("level", level);
>+    if (this.urlBar)
>+      this.urlBar.setAttribute("level", level);
>+    if (label) {
>+      try {
>+        this.securityButton.setAttribute("label", label);
>+      } catch(exception) {}

This try/catch was added by bug 245406, and although I'm not exactly sure what exception it was meant to catch, its almost certainly due to getting gBrowser.contentWindow.location.host and not the call to setAttribute (especially since there are other calls to this.securityButton.setAttribute just before and after in onSecurityChange). That means that factoring it out like this isn't OK (the callers will throw). It should be either removed entirely (if you can prove that no exceptions are expected) or moved back to the caller.

>   onSecurityChange : function(aWebProgress, aRequest, aState)

>+    // hide the feed button so we don't get flicker when we insert
>+    // a lock icon.
>+    FeedHandler.hideFeedButton();

So this means that when switching to tabs with both security and feed icons, we'll show the feed icon when onLocationChange is called, then hide it here, then show it again? That seems kinda suboptimal, and seems like a lot of extra work to fix a minor redrawing bug that can't consistently be reproduced. The "flicker" comes from the feed button "moving over" when the security icon is shown, right? Would this bug be solved by changing the position of the lock icon so that it's the left-most item? That's not exactly a clean fix either, but onSecurityChange is always going to be the last progress listener method called in the tab-switching case, so it could help.

	Robert Sayre Assignee
	Comment 12 • 18 years ago

(In reply to comment #11)
> its almost certainly due to getting
> gBrowser.contentWindow.location.host 

Ah yeah. Will fix.

> So this means that when switching to tabs with both security and feed icons,
> we'll show the feed icon when onLocationChange is called, then hide it here,
> then show it again? That seems kinda suboptimal, and seems like a lot of extra
> work to fix a minor redrawing bug that can't consistently be reproduced.

I can consistently reproduce it, and I don't see why we should worry about optimizing here.

	Robert Sayre Assignee
	Comment 13 • 18 years ago

fwiw, it's much easier to reproduce by tab switching between a plain http: page that has a feed, and an https: page that doesn't have a feed.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 14 • 18 years ago

I can reproduce this on the branch, but I can't on the trunk. Phil thinks this might have been fixed by bug 353194.

	Samuel Sidler (old account; do not CC) Reporter
	Comment 15 • 18 years ago

Yeah, I can't reproduce this on trunk either. Resolving WFM (Phil can change it if he's sure that 353194 fixed it).