Closed
Bug 684534
Opened 13 years ago
Closed 13 years ago
Larry icon image flickers from the wrong image to the right one
Categories
(Toolkit :: XUL Widgets, defect)
Tracking
()
RESOLVED
FIXED
mozilla16
People
(Reporter: jrmuizel, Assigned: dao)
References
Details
Attachments
(1 file)
(deleted),
patch
|
enndeakin
:
review+
|
Details | Diff | Splinter Review |
When you click on the site info dialog it shows the icon from the previous time it was displayed before showing the correct icon. For example, if you view it on a site with a blue DV cert and then switch to a page with a EV cert it will flash blue the icon before showing the green icon. This is disorienting and makes the UI feel sloppy.
Assignee | ||
Updated•13 years ago
|
Blocks: doorhanger
Comment 1•13 years ago
|
||
It sounds like you're talking about the site identity popup ("You are connected to" AKA "Larry" dialog viewable on HTTPS sites by clicking the domain button) rather than actual "doorhangers" (e.g. popup notifications you get when a site requests your location).
Also the icons aren't colored, the background button is, so I'm not sure I understand what is flickering. Need actual STR here...
Reporter | ||
Comment 2•13 years ago
|
||
I've only been able to reproduce this on Windows.
STR:
- Load two sites (one with EV and one without)
- Go to the non EV one and open Larry
- Switch to the EV one and reopen Larry
- The icon will quickly flash from blue to green
Reporter | ||
Updated•13 years ago
|
Summary: Doorhanger image flickers from the wrong image to the right one → Larry icon image flickers from the wrong image to the right one
Comment 3•13 years ago
|
||
We style the popup and set strings in setPopupMessages before opening the popup in handleIdentityButtonEvent:
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/browser.js#7852
which triggers this styling:
http://mxr.mozilla.org/mozilla-central/source/browser/themes/winstripe/browser/browser.css#2087
I guess the restyle doesn't occur until after the popup is open again. We could try forcing a restyle before opening the popup. I don't know why this would only affect windows, the styling is similar on all platforms AFAICT. Perhaps it's a panel issue, or maybe your Windows machine is just slow.
Comment 4•13 years ago
|
||
I don't see the icon flickering but I do often see the old text for the website name (the line that appears in bold) briefly before the new text appears.
Comment 5•13 years ago
|
||
That's pretty odd, given that we change the label values before we call openPopup(). Is this a Windows-only bug with panels in general?
I also see this on Windows. Haven't tried on another OS yet.
I only really notice it while my AV software is scanning my mozilla-central checkout, causing a lot of disk/CPU usage.
Assignee | ||
Comment 7•13 years ago
|
||
My current patch in bug 767133 works around this for all arrow panels.
Depends on: 767133
Assignee | ||
Updated•13 years ago
|
Assignee | ||
Comment 8•13 years ago
|
||
I'm splitting bug 767133 into multiple bugs, since the -moz-transform transition is causing failures that I don't know yet how to deal with.
This part differs from what you already reviewed in bug 767133:
1) The popup state is checked because test_arrowpanel.xul wants to reopen the panel during popuphidden.
2) browser_bug432599.js and browser_popupNotification.js didn't like that the popup is unhidden after a timeout. I replaced this with a layout flush.
By the way, it would be nice to know what's causing this bug and whether it could be prevented at a lower level or avoided on a per-panel basis (since it doesn't affect all panels, for unknown reasons).
Assignee | ||
Comment 9•13 years ago
|
||
(In reply to Dão Gottwald [:dao] from comment #8)
> By the way, it would be nice to know what's causing this bug and whether it
> could be prevented at a lower level or avoided on a per-panel basis (since
> it doesn't affect all panels, for unknown reasons).
Could it be that updating the panel contents before calling openPopup rather than during popupshowing triggers this?
Assignee | ||
Updated•13 years ago
|
Component: Location Bar → XUL Widgets
Product: Firefox → Toolkit
QA Contact: location.bar → xul.widgets
Updated•13 years ago
|
Attachment #636244 -
Flags: review?(enndeakin) → review+
Comment 10•13 years ago
|
||
(In reply to Dão Gottwald [:dao] from comment #8)
> By the way, it would be nice to know what's causing this bug and whether it
> could be prevented at a lower level or avoided on a per-panel basis (since
> it doesn't affect all panels, for unknown reasons).
Is this windows only? I couldn't reproduce it when I tried it earlier (comment 4). If we had a testcase, we could file a separate bug and I could investigate again.
Assignee | ||
Comment 11•13 years ago
|
||
I've only seen this on Windows.
Assignee | ||
Comment 12•13 years ago
|
||
Target Milestone: --- → mozilla16
Comment 13•13 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•