849216 - More than one button is highlighted in Social API

Status: VERIFIED FIXED

(Firefox Graveyard :: SocialAPI, defect)

Description

[Ada [:adalucinet]]

Attachment: Both issues captured

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?

Comment 1

[u279076]

Though the issue is intermittent, can you reproduce it at all in Firefox 19 or earlier?

Comment 2

[Mark Hammond [:markh] [:mhammond]]

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...

Comment 3

[Mark Hammond [:markh] [:mhammond]]

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

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 5

[Mark Hammond [:markh] [:mhammond]]

Attachment: open the popup in a setTimeout handler

Open the panel via setTimeout to avoid the problem described in comment 3.

Comment 6

[Bogdan Maris, Desktop Test Engineering]

(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.

Comment 7

[Mark Hammond [:markh] [:mhammond]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ac134bae8d29

Comment 8

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/ac134bae8d29

Comment 9

[u279076]

Alexandra, please verify that this is no longer reproducible for you with the latest Firefox Nightly.

Comment 10

[Bogdan Maris, Desktop Test Engineering]

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

[u279076]

Please report the text alignment issue in a new bug.