Zibi Braniecki [:zbraniecki][:gandalf] Reporter
	Description • 7 years ago

I noticed a bug on Facebook that has also been reported on reddit: https://www.reddit.com/r/firefox/comments/6lze7l/i_have_an_issue_with_firefox_when_using_facebook/

STR:
1) Open Facebook and open a chat box
2) Open Facebook in a new tab/window such as the chat box auto-opens
3) Click on the input box for a new post

Current result:
The input box disappears

Expected result:
The input box does not disappear.

	Zibi Braniecki [:zbraniecki][:gandalf] Reporter
	Comment 1 • 7 years ago

Screencast of an issue

	:Gijs (he/him)
	Comment 2 • 7 years ago

Karl, do you know if we have contacts at Facebook that can help figure out what's happening here?

	Vlad Bacia-Mociran [:VladB]
	Comment 3 • 7 years ago

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170711030203

I have tested your issue on latest Firefox release (54.0.1), latest Nightly (Build ID: 20170711030203) and managed to reproduce it. I have created a new Firefox profile in which I have opened Facebook for the first time. After I've logged in using a valid account I have clicked on a contact from Facebook chat list and the chat message window has appeared on screen as in the Screencast from comment 1. Click on the input box for a new post and wait. At this point the background selector should load but instead the input box disappears.

For the above scenario if we first click on the input box and wait for the background selector to load and then retest the scenario, the issue is no longer reproducible.

I could reproduce the issue only with a new Firefox profile or an old profile which had all history cleared (cookies, cache, etc) or using a Facebook account that has never been used on that Firefox profile. 

Reproducible also with Firefox Nightly versions from 2015, e10s ON and OFF.

Cannot reproduce on Chrome v60.0.3112.50 (Official Build) beta (64-bit) and IE 11.

	Olli Pettay [:smaug][bugs@pettay.fi]
	Comment 4 • 7 years ago

(no idea why this was moved to DOM: Events)

	:Gijs (he/him)
	Comment 5 • 7 years ago

Kannan, the grapevine says you might have contacts at Facebook who can help with this? I've been seeing this as have others, and it seems to reproduce with old builds, which suggest it might be related to a recent FB change (even if there's ultimately a bug in something we do somewhere, it's very much not clear what that would be).

	:Gijs (he/him)
	Comment 6 • 7 years ago

Moving to web compat, at least for now, and also pinging Mike in case he has clues / contacts.

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

Repro'd and got an internal stack trace, filed a FB task (Benoit, I cc'd you on the internal task). Thanks for flagging!

	:Gijs (he/him)
	Comment 8 • 7 years ago

Toning down the needinfos per comment #7. :-)

	Mike Taylor [:miketaylr]
	Comment 9 • 7 years ago

(thanks everyone!)

	Benoit Girard (:BenWa)
	Comment 10 • 7 years ago

This may be related to bug 921444.

	Zibi Braniecki [:zbraniecki][:gandalf] Reporter
	Comment 11 • 7 years ago

I just reproduced it on current nightly, with exactly the same behavior as in the video attached to this bug.

Mike, any progress on that issue internally?

	Jed Davis [:jld] (on leave until 08-31)
	Comment 12 • 7 years ago

For what it's worth, I don't think this is about the chat feature per se.  I used to have the input box disappear every time I tried to post, and found that it also happened in a new profile, on several OSes, with several versions including release, etc.  But currently (and I forget exactly when this changed; sorry) it works if I load the page and immediately post, but if I scroll down and interact with things and then go back up to the top to post, the text box disappears when clicked on.

	Benoit Girard (:BenWa)
	Comment 13 • 7 years ago

Last I looked it was disappearing because Firefox throws an error during the react render step because of Selection.extends(). It's some exception that we only see in Firefox but I'm not sure exactly why it is thrown.

	Zibi Braniecki [:zbraniecki][:gandalf] Reporter
	Comment 14 • 7 years ago

[Tracking Requested - why for this release]: This is a high-visibility bug for the 57 release. It seems to affect one of the most popular websites and the UX is visibly broken.

I can still reproduce it on 57 and Nightly.

	Mike Taylor [:miketaylr]
	Comment 15 • 7 years ago

(Adam also started a thread on our mailing list about this issue last week)

	Liz Henry (:lizzard) (relman/hg->git project)
	Comment 16 • 7 years ago

It would be good to fix this for 57. Not sure it should block the release, though, since it's not a new regression in 57. If the issue turns out to be something we can fix/workaround, it isn't too late to uplift to 57. 

Anything else we can do to help FB folks debug this?

	Karl Dubost💡 :karlcow
	Comment 17 • 7 years ago

Thomas, do you have an idea?

	Mike Taylor [:miketaylr]
	Comment 18 • 7 years ago

Sel. Collapse to 0x16511ac10 div 0
Sel. Collapse to 0x162c97310 div 1
Sel. Collapse to 0x162c97310 div 0
Sel. Collapse to 0x1183abbb0 textarea 0
Sel. Collapse to 0x1665f3400 #text 1
Sel. Collapse to 0x162c97310 div 1
Assertion failure: false (!IsValidSelectionPoint), at /Users/mitaylor/dev/gecko/dom/base/Selection.cpp:2980


#01: mozilla::dom::Selection::Extend(nsINode&, unsigned int, mozilla::ErrorResult&)[/Users/mitaylor/dev/gecko/obj-x86_64-apple-darwin17.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x284acc2]
#02: mozilla::dom::Selection::ExtendJS(nsINode&, unsigned int, mozilla::ErrorResult&)[/Users/mitaylor/dev/gecko/obj-x86_64-apple-darwin17.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x284abc1]
#03: mozilla::dom::SelectionBinding::extend(JSContext*, JS::Handle<JSObject*>, mozilla::dom::Selection*, JSJitMethodCallArgs const&)[/Users/mitaylor/dev/gecko/obj-x86_64-apple-darwin17.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x31a930c]
#04: mozilla::dom::GenericBindingMethod(JSContext*, unsigned int, JS::Value*)[/Users/mitaylor/dev/gecko/obj-x86_64-apple-darwin17.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x3ad2192]
#05: js::CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), JS::CallArgs const&)[/Users/mitaylor/dev/gecko/obj-x86_64-apple-darwin17.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x8882684]
#06: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct)[/Users/mitaylor/dev/gecko/obj-x86_64-apple-darwin17.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x88823e7]
#07: InternalCall(JSContext*, js::AnyInvokeArgs const&)[/Users/mitaylor/dev/gecko/obj-x86_64-apple-darwin17.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x8882a2d]
#08: js::CallFromStack(JSContext*, JS::CallArgs const&)[/Users/mitaylor/dev/gecko/obj-x86_64-apple-darwin17.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x888282d]
#09: Interpret(JSContext*, js::RunState&)[/Users/mitaylor/dev/gecko/obj-x86_64-apple-darwin17.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x8876e4a]
#10: js::RunScript(JSContext*, js::RunState&)[/Users/mitaylor/dev/gecko/obj-x86_64-apple-darwin17.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x886bc44]
#11: js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct)[/Users/mitaylor/dev/gecko/obj-x86_64-apple-darwin17.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x88824e5]
#12: InternalCall(JSContext*, js::AnyInvokeArgs const&)[/Users/mitaylor/dev/gecko/obj-x86_64-apple-darwin17.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x8882a2d]
#13: js::CallFromStack(JSContext*, JS::CallArgs const&)[/Users/mitaylor/dev/gecko/obj-x86_64-apple-darwin17.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x888282d]
#14: js::jit::DoCallFallback(JSContext*, js::jit::BaselineFrame*, js::jit::ICCall_Fallback*, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>)[/Users/mitaylor/dev/gecko/obj-x86_64-apple-darwin17.0.0/dist/NightlyDebug.app/Contents/MacOS/XUL +0x89b54ca]

	Mike Taylor [:miketaylr]
	Comment 19 • 7 years ago

Here's a screenshot of what we're crashing on, possibly (using this bit of code):

(function(orig){Selection.prototype.extend=function(){console.log('calls extend, ', this, arguments);orig.apply(this, arguments);}})(Selection.prototype.extend)

	Mike Taylor [:miketaylr]
	Comment 20 • 7 years ago

Sorry, hit submit too soon on Comment #18.

I added a MOZ_ASSERT(false, "!IsValidSelectionPoint) at https://dxr.mozilla.org/mozilla-central/source/dom/base/Selection.cpp#2994 in a debug build, and got the stack in Comment #18.

Masayuki-san, is this something you know more about? The steps to reproduce are as follows:

1. log into facebook.com
2. open a message window with anyone (my test account was sending messages to itself)
3. refresh the page
4. click inside the "What's on your mind, <person>?" input

After a second or two, or when you start to type, the input area will disappear and you'll get a NS_ERROR_FAILURE in the devtools. Will upload a screenshot of that.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 22 • 7 years ago

Sorry for the delay to reply. Looks like that if caused by calling Selection API to move selection outside of <textarea> which having focus? Like this:
https://jsfiddle.net/d_toybox/mhqpy46n/

If so, Selection should ignore selection limiter when it's called by JS.  The testcase doesn't work only on Gecko.

	Masayuki Nakano [:masayuki] (he/him)(JST, +0900)
	Comment 23 • 7 years ago

And also, this case:
https://jsfiddle.net/d_toybox/mhqpy46n/1/

	Liz Henry (:lizzard) (relman/hg->git project)
	Comment 24 • 7 years ago

Any further news from Facebook? 
Or, is there any workaround we can make for 57? If not, maybe for 58.

	Adam Stevenson [:adamopenweb]
	Comment 25 • 7 years ago

Received an update tonight that the fix is in production. Works for me now, tested in Firefox 57 & 58 in OSX.

	Mike Taylor [:miketaylr]
	Comment 26 • 7 years ago

That's great news. Thanks to FB for working on this.

	:Gijs (he/him)
	Comment 27 • 7 years ago

(In reply to Masayuki Nakano [:masayuki] (JST, +0900) from comment #22)
> Sorry for the delay to reply. Looks like that if caused by calling Selection
> API to move selection outside of <textarea> which having focus? Like this:
> https://jsfiddle.net/d_toybox/mhqpy46n/
> 
> If so, Selection should ignore selection limiter when it's called by JS. 
> The testcase doesn't work only on Gecko.

Should/Do we have a follow-up issue to fix this within Gecko?