bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.

invisible text when typing comments on facebook

RESOLVED FIXED in Firefox 43



Firefox for Android
3 years ago
3 years ago


(Reporter: hallvors, Assigned: kats)


Firefox 44

Firefox Tracking Flags

(firefox43+ verified, firefox44 verified, fennec43+)




(4 attachments)



3 years ago
When commenting on somebody else's status updates, sometimes the text you input is invisible until a forced repaint (switching tabs, scrolling off screen and back). See demo I'm about to attach, half-minimised.

Comment 1

3 years ago
Created attachment 8655998 [details]

OPen this in Firefox for Android and try to type a comment.

It seems to have something to do with work happening in the resize handler.

    function yb() {
        if (!window.innerHeight || window.innerHeight == pa) return;

This cb() method does some interesting stuff, it ends up here:

            dc && Object.assign(dc.style, hc);
            ec && Object.assign(ec.style, gc);

and that's where I'm going to keep digging unless somebody already knows what this is about..

Comment 2

3 years ago
Created attachment 8656489 [details]
Simplified test case - fb-textarea-repaint.html

There's still some superfluous markup (and lots of attributes that can likely be removed) but it's pretty minimal now.

Comment 3

3 years ago
David, this is about min-height on a container element being changed when the window resizes. It seems as if layout thinks the TEXTAREA is outside the rendered part of the page and therefore doesn't update it, or something like that. I don't know if this is a Core thing or a Firefox Android thing - I do know it's something we should fix ASAP since I keep running into this problem when using Facebook in FxAndroid. Can you comment on whether it's a core thing and can your or Brad Lassey find a dev to investigate it from the Android side if it isn't?
Flags: needinfo?(dbaron)
Flags: needinfo?(blassey.bugs)

Comment 4

3 years ago
Hm.. we might already have a fix in Nightly. I was testing in Nightly too, but after todays update I haven't seen this problem..
so, WFM?
Flags: needinfo?(blassey.bugs)

Comment 6

3 years ago
Hm.. No. I can still reproduce with the first (less simplified) test case attached here in latest nightly. I'm requesting this tracked for 43 because working on Facebook is important..
tracking-firefox43: --- → ?
I don't really know for sure, but given that I can't repro the bug with the testcase on either FxOS or desktop, I'm inclined to think it's an Android thing.  (I don't have a current Android build.)

But needinfo? to jwatt as well in case he sees otherwise.
Flags: needinfo?(dbaron) → needinfo?(jwatt)
Florin, can your team try to reproduce this? Thanks!
tracking-firefox43: ? → +
Flags: needinfo?(florin.mezei)
I've tried to reproduce this using the latest 43 Nightly build (e10s on and off) on Windows 7 x64, Mac OS X 10.8.5, and Ubuntu 12.04 x64, using both testcases.
Flags: needinfo?(florin.mezei)
(In reply to Florin Mezei, QA (:FlorinMezei) from comment #9)
> I've tried to reproduce this using the latest 43 Nightly build (e10s on and
> off) on Windows 7 x64, Mac OS X 10.8.5, and Ubuntu 12.04 x64, using both
> testcases.

... with no success. Desktop does not seem to be affected by this.
I was able to reproduce this issue a few times using the simplified test case on Sony Xperia Z2 10" running Android 5.0.1 and on N7 running Android 5.1.1

Build: Latest Nightly
1. Put the tablet on landscape (wasn't able to reproduce in portrait mode)
2. Load https://bugzilla.mozilla.org/show_bug.cgi?id=1201076
3. Long tap on  'Simplified test case - fb-textarea-repaint.html' link and 'Open Link in New Tab'
4. Wait a few seconds for the new page to fully load
5. Switch to the new tab, tap on textarea and start typing

Result: The text is not displayed until the page is re-painted

Note: This is not 100% reproducible for me. Sometimes the text is displayed when starting to type.
OS: Unspecified → Android
Hardware: Unspecified → ARM
Version: unspecified → Trunk

Comment 12

3 years ago
I've never seen it happen on desktop or Fx OS devices, only on Android.
Thanks Florin and Catalin. Yes, I think this is an android-only bug, I just don't have room on my phone to install FB so thought it might help to call in extra help. 

Margaret, or Mark, can you help us find an owner for this bug? Thanks.
tracking-fennec: --- → ?
status-firefox43: --- → affected
Flags: needinfo?(mark.finkle)
It's possible this is an IME bug (jchen) or a rendering bug (kats has been touching code lately).

Catalin - Can we get a regression range for Android?
Assignee: nobody → snorp
tracking-fennec: ? → 43+
Flags: needinfo?(nchen)
Flags: needinfo?(mark.finkle)
Flags: needinfo?(catalin.suciu)
Flags: needinfo?(bugmail.mozilla)
My best guess is that this has the same root cause as bug 1202290 and the patch there (now on inbound) should fix it.
Flags: needinfo?(bugmail.mozilla)
Created attachment 8659794 [details]

This is not a recent regression. Using the simplified test case, I'm able to reproduce even on Firefox 37

I see the following line being logged over and over when the bug is manifesting: 
D/GeckoLayerClient(28855): Aborting update due to viewport not in display-port
Flags: needinfo?(catalin.suciu)

Comment 17

3 years ago
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #13)
> don't have room on my phone to install FB 

(Just for the record: I'm seeing this on the normal m.facebook.com website, haven't added an app or anything)

Comment 18

3 years ago
Kats: bug 1202290 fix is in nightly now, right? Just tested with a fresh Fennec nightly, and I still see this problem on Facebook :-/
Flags: needinfo?(bugmail.mozilla)
I have been able to reproduce this, but due to a series of build issues (the latest being bug 1206484) I haven't been able to create my own debug builds yet.
Flags: needinfo?(jwatt)
(In reply to Hallvord R. M. Steen [:hallvors] from comment #18)
> Kats: bug 1202290 fix is in nightly now, right?


> Just tested with a fresh
> Fennec nightly, and I still see this problem on Facebook :-/

Seems my "best guess" was incorrect. Since it goes back to Firefox 37 (per comment 16) it was probably regressed by something else.
Flags: needinfo?(bugmail.mozilla)
Keywords: regressionwindow-wanted

Comment 21

3 years ago
This code is last touched by Chris Lord or kats, according to hg blame:
- although I guess the bug may be in the values rather in the logic? Would still be nice if either of you could quickly check which value is wrong..
Flags: needinfo?(chrislord.net)
Flags: needinfo?(bugmail.mozilla)
The code this interacts with has been restructured/written multiple times since I last touched it, I don't think I can be of much immediate help here.
Flags: needinfo?(chrislord.net)
Bug 1204982 has the same underlying cause, I think - in both cases the paint is aborted by the Java code since there is a displayport/viewport mismatch but then there is no future paint, which the Java code assumes will happen. I think it might be best to just remove the hunk from GeckoLayerClient entirely. I'll make a try build for people to try out. Leaving ni on me for now.
I can reproduce this intermitently with the reduced test case. Looks like the Java side scroll position ends up stale which is a different bug than what I was expecting. I'll investigate further.
Assignee: snorp → bugmail.mozilla
Flags: needinfo?(bugmail.mozilla)
The problem appears to be that there's an animation in progress on the Java side when the page size changes, and so the page size (and corresponding clamped scroll position) gets lost. The animation just clobbers it.
Created attachment 8665556 [details] [diff] [review]

Kinda ugly and very specific but it's the least risky fix I can think of that works. Basically, since bounce animations never change the CSS page size, don't allow them to clobber the CSS page size that exists in the GeckoLayerClient.

Try push at https://treeherder.mozilla.org/#/jobs?repo=try&revision=23b64703be95
Attachment #8665556 - Flags: review?(snorp)
Comment on attachment 8665556 [details] [diff] [review]

Review of attachment 8665556 [details] [diff] [review]:

I don't understand this at all, but ok...
Attachment #8665556 - Flags: review?(snorp) → review+
Last Resolved: 3 years ago
status-firefox44: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 44
Flags: needinfo?(nchen)
Blocks: 1204982
Comment on attachment 8665556 [details] [diff] [review]

Approval Request Comment
[Feature/regressing bug #]: unknown, been in the tree for a while
[User impact if declined]: when typing comments in facebook the text is sometimes invisible
[Describe test coverage new/current, TreeHerder]: tested locally on a simplified test case. nobody has verified the fix on the original problem and there is not esting.
[Risks and why]: medium risk, this code is brittle and not well tested. i tried to make the patch affect as few codepaths as possible to reduce the risk.
[String/UUID change made/needed]: none
Attachment #8665556 - Flags: approval-mozilla-aurora?
Catalin, can you verify this on m-c now? 
I'm reluctant to uplift a patch in this state, especially if it isn't a recent regression.
Flags: needinfo?(catalin.suciu)
I'm not able to reproduce this issue on latest Nightly, using the attached test cases.
Tested on Sony Xperia Z2 running Android 5.0.2 and N7 running Android 5.1.1
status-firefox44: fixed → verified
Flags: needinfo?(catalin.suciu)
Comment on attachment 8665556 [details] [diff] [review]

Tentative fix; may be risky but fixes a bad regression and is verified on nightly.
Attachment #8665556 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Keywords: regressionwindow-wanted

Comment 35

3 years ago
I'm not able to reproduce this issue on latest Aurora 43.0a2 10-12-2015
Tested on Sony Xperia Z2(Android 5.0.2) and Samsung Galaxy S6 Edge (Android 5.1.1)
status-firefox43: fixed → verified
You need to log in before you can comment on or make changes to this bug.