Bug List: (412 of 944) First Last Prev Next   Show last search results
x [help]  
x
Last Comment Bug 1234276 - Images on https://translate.google.com/ blink every time I enter/exit Responsive Design Mode (edit)
:
:
Status: NEW (edit) [NEEDINFO]
:
(show info)
Shared components used by Firefox and other Mozilla software, including handling of Web content; Gecko, HTML, CSS, layout, DOM, scripts, images, networking, etc. Issues with web page layout probably go here, while Firefox user interface issues belong in the Firefox product. (More info)
(show other bugs) (show info)
Bugs related to the layout of images. Use ImageLib for issues with the decoding of images.
:
:
: (vote)
:
Assigned To:

:
(edit) (take)

Mentors:
(edit)

https://translate.google.com/ (edit)
Depends on: (edit)
Blocks: 1207355 (edit)
  Show dependency tree / graph
What do these fields mean?
 
Reported: 2015-12-21 10:36 PST by
Modified: 2016-03-21 19:24 PDT (History)

8 users (edit)
  • bernesb@gmail.com
  • bugs@junglecode.net
  • dholbert@mozilla.com
  • dougt@mozilla.com
  • jmathies@mozilla.com
  • paul@mozilla.com
  • seth@mozilla.com
  • tnikkel@gmail.com


(never email me about this bug)
dholbert:
tnikkel:
addl.
(more flags)
(add)
Crash Signature:
(edit)
---
---
---
(edit)
---
---
---
---
wontfix
---
wontfix
---
affected
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---
---

Attachments
screencast 1 - All images on the page blink.webm (157.17 KB, video/webm)
2015-12-21 10:36 PST, 		no flags Details
View All Add an attachment (proposed patch, testcase, etc.)

Summon comment box


User Story (edit)

[wrap] [tag] [reply] [−] Description 2015-12-21 10:36:52 PST 
Created attachment 8700698 [details]
screencast 1 - All images on the page blink.webm

>>>   My Info:   Win7_64, Nightly 46, 32bit, ID 20151221030239
STR:
1. Open https://translate.google.com/
2. (Quickly?) press Ctrl+Shift+M to enter/exit Responsive Design Mode several times

Result:       All images on the page blink when I enter/exit Responsive Design Mode
Expectations: Images should not blink

Regressed between 2015-10-30 and 2015-10-31 by bug 1207355
> pushlog_url:   https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=99a4fb4ba5c1ee96ac745c6ad11894bf0537f73a&tochange=2e19045ba652ca2a5a5fc0e20d6f95293acfa32d
[tag] [reply] [−] Comment 1 2015-12-21 11:20:53 PST 
I can reproduce this 
fairly reliably, using current Nightly. (I see this happen with the 
"Google" word-logo in the upper-left, as well as the watering can 
towards the bottom of the left.

Seth, mind taking a look?
CC: dholbert@mozilla.com, seth@mozilla.com
Flags: needinfo?(seth@mozilla.com)
2015-12-21 15:09:02 PST
CC: tnikkel@gmail.com
2016-01-04 01:54:16 PST
Has STR: --- → yes
[wrap] [tag] [reply] [−] Comment 2 2016-03-14 00:41:41 PDT 
(In reply to Daniel Holbert [:dholbert] from comment #1)
> I can reproduce this fairly reliably, using current Nightly. (I see this
> happen with the "Google" word-logo in the upper-left, as well as the
> watering can towards the bottom of the left.

I was able to repro this one in FF45 but not in Nightly, likely because of the fix for bug 1225934.
CC: bugs@junglecode.net
[tag] [reply] [−] Comment 3 2016-03-14 04:09:09 PDT 
Reproducible on:   Win7_64, Nightly 48, 32bit, ID 20160313030418
2016-03-14 09:33:15 PDT
CC: bernesb@gmail.com
[tag] [reply] [−] Comment 4 2016-03-14 10:06:57 PDT 
Like arni, I can still 
reproduce this in Nightly, though it it subjectively seems like the 
flicker-pause has gotten shorter. (not sure)

(I tested using 48.0a1 (2016-03-12), which is well after bug 1225934 landed. So, I suspect bug 1225934 didn't fix this.)
[tag] [reply] [−] Comment 5 2016-03-18 16:39:15 PDT 
can we fix or back out asap?
CC: dougt@mozilla.com
Flags: needinfo?(bugs@junglecode.net)
[tag] [reply] [−] Comment 6 2016-03-18 16:53:28 PDT 
I don't think a backout
 would make sense at this point.  The only known STR involve a pretty 
niche use-case [rapidly switching into/out of responsive mode], and in 
current Nightly, the symptom is very brief & subtle -- it's much 
less noticeable than in the attached screencast.  And backing out would 
involve a good deal of risk, since the regressing bug, bug 1207355,
 seems to have been decently complex, and landed ~5 months ago, and has 
had several followups land afterwards that depend on it -- e.g. bug 1151359, bug 1225934.

So, cost/benefit of a backout doesn't make sense to me.

I agree we should investigate & fix this ASAP, though. Needs 
attention from either seth or tn, who were involved on the regressing 
bug.
Flags: needinfo?(tnikkel@gmail.com)
[tag] [reply] [−] Comment 7 2016-03-18 17:14:19 PDT 
For the record, here's a
 screencast on YouTube comparing the STR on Firefox 44 (left, unaffected
 by this bug) to Firefox 45 (center, affected) & current Firefox 
Nightly (right, affected).

(As shown in that screencast: instead of exhibiting this bug [with just 
the images blinking], Firefox 44 seems to exhibit something a bit worse 
-- the full viewport blinking blank instead.  Maybe this is because our 
full-page paint was blocked on the image being synchronously decoded, or
 something like that? Not sure.)
[tag] [reply] [−] Comment 8 2016-03-18 17:14:41 PDT 
Screencast link: https://www.youtube.com/watch?v=1tKDOPiHRpw
[tag] [reply] [−] Comment 9 2016-03-18 21:17:15 PDT 
The affected images 
have Discard called on them because the presentation for the content 
document is destroyed. The presentation is destroyed when we leave 
design mode because of this code (which is called via restoreScrollbars)

http://mxr.mozilla.org/mozilla-central/source/devtools/client/responsivedesign/responsivedesign-child.js?rev=a88b9e9d747a#142

which comes from bug 1067145
 and doesn't really have a clear explanation that I can find for why 
it's needed. The code (and the comment) seem explicitly crafted to 
destroy the presentation. Since all the calls to flushStyle happen after
 adding or removing a style sheet, it seems the point is to ensure that 
stylesheet add/remove takes effect. But recreating an entire 
presentation seems overkill for that, is that actually needed?
Flags: needinfo?(tnikkel@gmail.com)
2016-03-18 21:17:30 PDT
CC: paul@mozilla.com
Flags: needinfo?(paul@mozilla.com)
2016-03-21 14:06:47 PDT
CC: jmathies@mozilla.com
status-firefox46: affected → wontfix
status-firefox47: --- → wontfix
status-firefox48: --- → affected
[wrap] [tag] [reply] [−] Comment 10 2016-03-21 19:24:37 PDT 
(In reply to Daniel Holbert [:dholbert] from comment #6)
> I don't think a backout would make sense at this point.  The only known STR
> involve a pretty niche use-case [rapidly switching into/out of responsive
> mode]

Let's not back out over this one. I'm curious about why responsive mode requires that it tear down the entire presentation per comment 9.
Flags: needinfo?(bugs@junglecode.net)
:
Generating Preview...
(In reply to Daniel Holbert [:dholbert] from comment #6)
> The only known STR involve a pretty niche use-case [rapidly switching into/out of responsive mode]
I see it after each switching, no matter how "rapid" it is. Just like written in the Summary.

> and in current Nightly, the symptom is very brief & subtle --
> it's much less noticeable than in the attached screencast.
You're comparing performance on your PC to performance on my PC. On 
Nightly 2016-03-18 (your comment says "current Nightly") the synptom is 
the same as it was in 45. Probably you have super-fast machine

(In reply to Daniel Holbert [:dholbert] from comment #7)
> For the record, here's a screencast on YouTube comparing the STR on Firefox 44 to Firefox 45
> (As shown in that screencast: instead of exhibiting this bug, Firefox 44 seems to exhibit
> something a bit worse -- the full viewport blinking blank instead.
How it this releavent anyway? You're comparing some non-e10s build far from last good build.
You should've compared exactly last good and first bad builds for this to be 100% relevant.

(In reply to Jet Villegas (:jet) from comment #10)
> (In reply to Daniel Holbert [:dholbert] from comment #6)
> > The only known STR involve a pretty niche use-case [rapidly switching into/out of responsive mode
> 
> Let's not back out over this one. I'm curious about why responsive mode requires that it
> tear down the entire presentation per comment 9.
Yes, please. Especialy since that was obviously a false statement (about "the only known STR").

Screencasts:
(in each testing I first switch mode relatively slow, then - very fast)
> [1] last good vs first bad    https://dl.dropboxusercontent.com/s/37apm9uuk9p49tf/bug%201234276%20comment%2011%201.webm?dl=0
> [2] first bad vs 2016-03-18   https://dl.dropboxusercontent.com/s/nm68olqsuls4uwn/bug%201234276%20comment%2011%202.webm?dl=0

Status:
of <missing> (edit)
Bug List: (412 of 944) First Last Prev Next   Show last search results

Privacy Policy