Closed Bug 987429 Opened 9 years ago Closed 7 years ago : rapid repainting, links don't work (needs account)


(Web Compatibility :: Mobile, defect)

Not set



tracking-b2g backlog


(Reporter: dietrich, Unassigned)




(Whiteboard: [mobile-compat-form] [needsdiagnosis])

rapid repainting, links don't work

:: Steps To Reproduce

1. open the page
2. try to use anything on it

:: Expected Result

no crazy repainting, touch an article and expect it to open

:: Actual Result

crazy repainting, articles don't open

:: Additional Information

Software Version: 1.5
Device Information: Nexus 4
Reporter's User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Firefox/31.0
Hi Dietrich,

thanks for the bug report. I want to understand better what the bug is about:
You selected Platform: Firefox OS
Then for device information: "Nexus 4"
And software version: "1.5"

Is it an issue happening only on Firefox OS, does it happen on Firefox for Android?
Does it happen on other mobile browsers such as Safari, Opera Android, etc?

What is "crazy repainting"? :)
When getting to
without a user account, the user is redirected to
Human ping about the comment #1
Flags: needinfo?(dietrich)
I don't have an Android phone on me to test, and Pocket won't even let you get the desktop content on iOS, just a link to install the app. I can test Firefox on Android tomorrow.

The crazy repainting is basically that sections of the page are rapidly flashing rapidly.

Yes, my test was logged in, viewing the list of saved articles.
Flags: needinfo?(dietrich)

I just tried with iOS Safari with a Google Test account. The experience is not completing on the Web. It opens a new window for Google Accounts, requests to accept some authorization and then gives a blank page.

On Firefox OS, it redirects to Google Play (same Google Test Accounts), and think we are an Android device.
So that's a first issue.

I guess you have a personal account on getpocket directly. Have you tested for Firefox for Android. Can you try on Opera Android too, and UCWeb Android too. 

Flags: needinfo?(dietrich)
Yes, I have a personal account, and am logged in, as from my comments so far have alluded.

Android Firefox, Opera and UCWeb all get a prompt for installing the Android app, even when logged in.

On Firefox OS in my tests, I can log in and see my list of saved articles. However, also with the deficiencies described in comment #0. I'm using a developer build, so quite possibly there are UA differences between what you're sending and what I'm sending.
Flags: needinfo?(dietrich)
Summary: rapid repainting, links don't work → : rapid repainting, links don't work (needs account)
Jason, what do you recommend in that case? Do we go through a cycle of QA?
Flags: needinfo?(jsmith)
Sure. Flagging qawanted to see if we can reproduce on the latest 2.0 Flame build.
blocking-b2g: --- → backlog
Flags: needinfo?(jsmith)
Keywords: qawanted
This issue partially reproduces in the latest 2.0 Flame build

when loading (after setting up account and adding links / articles) I do see the rapid repainting, however, the links to the articles I've saved DO work.

Video here:
 - you can see the frames and pictures re-drawing constantly. Also - the vertical scroll bar indicator on the far right side shifts left and right as you scroll (seen toward end of video)

Device: Flame 2.0
Build ID: 20140730080807
Gaia: e8425788e0372fbbcc40387b799f0636c041fc14
Gecko: 20c472fc0ee3
Version: 32.0 (2.0)
Firmware Version: v122
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][lead-review+]
Could somebody E-mail me a user name/password (if you set up a throwaway account already)?
blocking-b2g: backlog → ---
In accordance to
Requalifying the bug, the issue is happening on Firefox Android too.
Ever confirmed: true
OS: Gonk (Firefox OS) → Android
Hardware: Other → ARM
I confirm the described behavior and this is happening because of this rule.

.overlay_screen .content_container::before {
	content: '';
	display: inline-block;
	height: 100%;
	vertical-align: middle;
	margin-right: -.25em;

Once you deactivate the 

* `content:''` 
* or `height: 100%`
* or `display: inline-block;`,

the rest of the page appears.

This combination doesn't have the same effect in Blink and WebKit it seems.

Daniel, do we have a bug about a combination of these properties
or do you remember a bug in Blink/WebKit?
Flags: needinfo?(dholbert)
That sounds like  (which really turned out to be a problem with another element (*after* the pseudo-element) rendering differently (bigger) in Firefox than in Chrome.  (I filed bug 1244192 for more investigation of that discrepancy in Gecko; if this happens to be exactly the same sort of failure, then we might want to tie this to that bug.)

That might be what's going on here, too. Karl, if you're already poking around at this in devtools, could you see if there's something like that here? (some element after the pseudo-element which is being forced to wrap to the next line because it's a bit wider for us)
Flags: needinfo?(dholbert) → needinfo?(kdubost)
Thanks daniel.

ok found a bit more details. When emulating on Desktop with resizing the viewport.
The screen is blank if the width is 372px or less and appears as soon as the width is 373px.

The markup around this is:

<div style="height: 640px;" class="content_container">
    <div class="content_detail">
        <div class="overlay_createpasswordcontainer">

.content_container is 360px wide
.content_detail    is 376px wide (so larger)

And the CSS is 

.overlay_screen .content_detail {
	color: #fff;
	font-family: proxima-nova,"Helvetica Neue",Helvetica,Arial,sans-serif;
	font-size: 22px;
	font-weight: 600;
	display: inline-block;
	text-shadow: 1px 1px 0 rgba(0,0,0,.2);
	vertical-align: middle;
	width: auto;

It seems to be the same type of bug.
Flags: needinfo?(kdubost)
The design of seems to have changed. and it seems to work smoothly.
Closed: 7 years ago
Resolution: --- → FIXED
Whiteboard: [mobile-compat-form] → [mobile-compat-form] [needsdiagnosis]
Yup, looks good to me too - paint flashing indicates there's no rapid repainting at this point (using today's 64-bit Linux Nightly 51), and I haven't seen any issues with links not working.
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.