Closed Bug 835111 Opened 8 years ago Closed 8 years ago
Facebook messages conversation box opens in a different window
I have a few windows open. I click the Facebook message icon in the top right. I get a drop-down of conversations. I click one. Nothing appears to happen. Turns out that a tiny box with a name has appeared at the bottom of a different window. Switching to that window allows me to have the conversation as expected. The selected window is always consistent: if I click through the sequence in that window, I get the tiny name box in that window. The expected behavior is for new conversation views to appear in my frontmost window, not in whichever window it used at some point in the past. I see this in the console (not sure if related): Timestamp: 2013-01-26 Jan 26 21:04:55 Error: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMHistory.replaceState] Source File: https://fbstatic-a.akamaihd.net/rsrc.php/v2/ya/r/E-6Q2pI-TPI.js Line: (null)
I don't suppose this is a dupe of bug 807997? We don't show chat windows in popup or "chromeless" windows, and used to have an inconsistency between supporting the sidebar in a given window and supporting the chats it potentially opened.
I can repro this when the sidebar is closed, and it is by (poor) design. Facebook opens the chat window via our worker (and thus we don't get a hint about what window the user was interacting with). When this happens, we try and locate a top-level Window with chats already open and open the chat there (in an attempt to "group" all the chats in the same place - eg, consider the edge-case of an incoming chat when all windows are minimized). This attempt to be smart is probably misguided. We could either try and make this smarter still (eg, explicitly check for windows being minimized etc), or just drop the smarts completely - always use the "most recent" window and accept that chats may end up spread between the various opened windows. Chatting with Gavin, I think we are leaning towards the latter. [FWIW, this could be mitigated by Facebook in this specific case (by having the panel itself open the chat instead of the worker), but the same general problem would exist for an unsolicited incoming chat, which could *not* be mitigated by them]
Assignee: nobody → mhammond
Status: NEW → ASSIGNED
Component: SocialAPI: Providers → SocialAPI
OS: Mac OS X → All
Hardware: x86 → All
Confirming that I have the sidebar closed. (Vertical tabs + Todoist is already cramping my browsing!)
This patch takes the minimal approach of never attempting any grouping for chats. We stick with the enumerator loop as the window returned by getMostRecentWindow() may be chromeless and therefore not suitable as the chat hosting window.
Comment on attachment 709981 [details] [diff] [review] Always use the most recent browser window that can host chats I don't think there is any easy solution to chat and multiple window, so keeping it simple and then getting some UR/UX time might help get a better handle on how to deal with this.
Attachment #709981 - Flags: feedback?(mixedpuppy) → feedback+
(In reply to Shane Caraveo (:mixedpuppy) from comment #5) > I don't think there is any easy solution to chat and multiple window, so > keeping it simple and then getting some UR/UX time might help get a better > handle on how to deal with this. If I were to speculate, putting aside my developer hat: once chats can be open in different windows, I'd want a click on a chat in the Messenger toolbar menu to bring that chat to this window, regardless of where it is (same behavior as if I closed it in whatever window it was in, then opened it again). Beyond that, the risk is that we're converging on window management: gather chats, close all open chats, find the chat that's beeping at me…. And when you get to that point, maybe you should open Facebook in a window!
hmm, another possibility is that all chats move to the topmost window, using a similar technique that the iframes for status panels use.
Comment on attachment 709981 [details] [diff] [review] Always use the most recent browser window that can host chats "first" is kind of a confusing name, since it refers to the last element in the bottom-to-top sorted array of windows. topMostChatWindow? You can also get rid of the "best" variable declaration.
Attachment #709981 - Flags: feedback?(gavin.sharp) → review+
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 21
Verified fixed in Firefox 21.0b6.
Status: RESOLVED → VERIFIED
With Firefox 22.0a2 on Linux, the chat boxes aren't opened in the most recent browser window.
They always appear in the last opened window.
(In reply to Marco Castelluccio [:marco] from comment #12) > With Firefox 22.0a2 on Linux, the chat boxes aren't opened in the most > recent browser window. They always appear in the last opened window. I'm not seeing this. Every time I have a chat it opens in the currently active window. Can you please provide more detailed steps to reproduce? FWIW, this should be fixed in Firefox 21 and above.
1) Open a new window 2) Switch to another window 3) Open a chat from the messages menu (or wait for an incoming message) The chat will be in the last opened window and not in the most recently used window. If I have a chat box opened in window A and open a new window B, when a new message from that person arrives, a new chat box is opened in B. So at the end there are two chat boxes, one in A and one in B, for a single conversation.
For me the chat opens in the currently active window in all cases. The duplicate chat windows is not something this bug was intended to address, as far as I know. I'm fairly certain there is a bug on file for this case but I can't find it right now. Feel free to file a new bug.
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #16) > For me the chat opens in the currently active window in all cases. The > duplicate chat windows is not something this bug was intended to address, as > far as I know. I'm fairly certain there is a bug on file for this case but I > can't find it right now. Feel free to file a new bug. Ok, I'll file a new bug for that. What about this bug? Can I do something to help you find the cause of the problem?
There's nothing more to be done on this bug. As far as I can tell it's working as designed.
You need to log in before you can comment on or make changes to this bug.