Closed
Bug 849216
Opened 12 years ago
Closed 12 years ago
More than one button is highlighted in Social API
Categories
(Firefox Graveyard :: SocialAPI, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
Firefox 22
People
(Reporter: adalucinet, Assigned: markh)
Details
Attachments
(2 files)
47.76 KB,
image/jpeg
|
Details | |
1.37 KB,
patch
|
Felipe
:
review+
|
Details | Diff | Splinter Review |
Reproducible on the latest Beta (BuildID: 20130307075451): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0
Reproducible on the latest Aurora (BuildID: 20130307042016): Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20130307 Firefox/21.0
Reproducible on the latest Nightly (BuildID: 20130306031012): Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:22.0) Gecko/20130306 Firefox/22.0
Steps to reproduce:
1. Start Firefox.
2. Navigate to https://www.facebook.com/about/messenger-for-firefox and click "Turn on" messenger for Firefox.
3. Randomly click the buttons (Notifications, Friend requests, Messages).
Expected results: Only the clicked button is highlighted.
Actual results: More than one button is highlighted.
Note:
1. This issue is intermittent, so I can’t find a reliable regression range.
2. Here is a screencast showing this issue: http://www.screencast.com/users/AlexandraLucinet/folders/Default/media/91838ffe-639d-4f62-b4dc-062e0f17d919
3. As seen in the screencast and attachment, the "No messages" and "No new notifications" messages from the panels are not displayed properly (as "No new requests" is). Should I file a new bug with this?
Though the issue is intermittent, can you reproduce it at all in Firefox 19 or earlier?
Assignee | ||
Comment 2•12 years ago
|
||
The following repro WFM reliably on trunk:
* Click the left-most ("friend requests") icon - panel opens.
* Click the middle button - panel closes.
* Click the left-most button again - panel opens and *both* left and middle buttons appear to be pressed.
I'll see what I can dig up...
Assignee | ||
Comment 3•12 years ago
|
||
This is caused by multiple popupshown and popuphidden handlers being added for the panel. The cause of this is:
* click on the left-button - new popup handlers added. popup shows, so first popup handler is (correctly) removed.
* click on the middle button - this causes the popup to hide, so second popup handler from above is (correctly) removed. We still attempt to show the popup, so new popup handlers are added. However, our call to openPopup actually fails to open the popup - internally the panel code knows we just "rolled up" the panel, so it silently refuses to re-open it (which is the reason that second click on the middle toolbar doesn't actually open the popup again).
Note that at this point we have added popupshown and popuphidden handlers, but the popup isn't going to be shown (or hidden) and therefore the handlers will not be removed.
* Click on the left-toolbar button again. A second set of popupshown/popuphidden handlers are added. The popup shows, so *both* sets fire - on both the left button and the middle button. Thus, both buttons get the "open" attribute so appear to be pressed.
So, the question is: what behaviour do we want WRT that second click not opening the panel?
* If it is correct that the click on the middle button should not show the panel, then the solution is to make sure we remove old handlers before we add new ones (ie, to ensure we never end up with multiple popupshown/popiphidden handlers).
* If we would like the click on the middle button to show the popup, the fix is very simple - move the openPopup() call to a setTimeout() function. This way, the popup internal code no longer thinks it just "rolled-up" the popup so allows it to open.
I've patches for both cases - but which one do we want?
Gavin, any thoughts?
Comment 4•12 years ago
|
||
I think having the other buttons be responsive when the panel is open is probably the right behavior. That's how the facebook.com web site works, anyhow.
Assignee | ||
Comment 5•12 years ago
|
||
Open the panel via setTimeout to avoid the problem described in comment 3.
Assignee: nobody → mhammond
Attachment #723796 -
Flags: review?(felipc)
Comment 6•12 years ago
|
||
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #1)
> Though the issue is intermittent, can you reproduce it at all in Firefox 19
> or earlier?
This issue is reproducible on all releases from 19.0.2 to 17.0 (16 does not support this), 17.0esr included.
Updated•12 years ago
|
Attachment #723796 -
Flags: review?(felipc) → review+
Assignee | ||
Comment 7•12 years ago
|
||
Comment 8•12 years ago
|
||
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 22
Alexandra, please verify that this is no longer reproducible for you with the latest Firefox Nightly.
Keywords: verifyme
Comment 10•12 years ago
|
||
Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:22.0) Gecko/20130315 Firefox/22.0
The part with the highlight of the buttons is not reproducible anymore on latest Nightly (buildID: 20130315030943), but "No messages" and "No new notifications" messages from the panels are not displayed properly (as "No new requests" is) just like in screenshot from comment 0.
Comment 11•12 years ago
|
||
Please report the text alignment issue in a new bug.
Status: RESOLVED → VERIFIED
Keywords: verifyme
Updated•6 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•