1074631 - m.chosun.com - user is unable to scroll on Firefox OS

Status: RESOLVED WONTFIX

(Web Compatibility :: Site Reports, defect, P5)

Description

[jeremy.kim.leo [:jeremykimleo]]

Steps to reproduce:

1. Launch browser and go to http://m.chosun.com
2. check all resources loaded completely
3. go to turn off screen by power key, 
4. push power key to turn on screen and release lockscreen
   , return to browser

Actual results:
1. user can't scroll on browser screen.

Expected results:
user possible to scroll pages of http://m.chosun.com

[Flame]-[v2.0]
gecko : a68af60d0d4b00b5a7e7c1633e2bf3e970463f0d
gaia : 5c2303ec4e367da060aa1b807d541a6549b3d72a

i just pulled and re-build with latest version in locally.

Comment 1

[Doyun Kim]

Reproduced on Flame 2.0 also.

Comment 2

[Rachelle Yang [:ryang][[e-mail]]]

Hi, I can't reproduce the issue from my side.

Please provide the detailed build information (below)and video STR otherwise we won't proceed the issue any further. Thanks!

including 
gaia revision
gecko revision
build-ID 
gecko version
firmware version
occurrence rate 

thank you very much.

Comment 3

[jeremy.kim.leo [:jeremykimleo]]

Attachment: 20141007_1358562014_10_07.avi

this is movie to understand this bug.

Comment 4

[jeremy.kim.leo [:jeremykimleo]]

(In reply to Rachelle Yang [:ryang][[e-mail]] from comment #2)
> Hi, I can't reproduce the issue from my side.
> 
> Please provide the detailed build information (below)and video STR otherwise
> we won't proceed the issue any further. Thanks!

opps, because this is 100%, i didn't describe more information.
anyway, please reference Comment3, it will be helped for your understanding.

and this is version information of flame-v2.0
$> BRANCH=v2.0 config.sh flame-kk
gecko : a68af60d0d4b00b5a7e7c1633e2bf3e970463f0d
gaia : 5c2303ec4e367da060aa1b807d541a6549b3d72a

i did compiled myself with last SEP-30. so, has no build-ID.
if you needs more information, please remains comment here. 

thanks

Comment 5

[Rachelle Yang [:ryang][[e-mail]]]

Hi Ben,

Could you please kindly help us look into this? Thank you very much.

Comment 6

[Rachelle Yang [:ryang][[e-mail]]]

[Blocking Requested - why for this release]:
partner requested as blocker. nominate to 2.0 ?

Comment 7

[jeremy.kim.leo [:jeremykimleo]]

remove ni to me.

Comment 8

[Ben Francis [:benfrancis]]

I can reproduce this on master as well. I don't need to lock the screen, just wait for a while after loading the page. The page can still be interacted with, but it becomes un-scrollable.

Chris, this looks like it could be a platform issue (or something site specific). Do you know which component we should put this in for further investigation?

Comment 9

[Chris Lord [:cwiiis]]

(In reply to Ben Francis [:benfrancis] from comment #8)
> I can reproduce this on master as well. I don't need to lock the screen,
> just wait for a while after loading the page. The page can still be
> interacted with, but it becomes un-scrollable.
> 
> Chris, this looks like it could be a platform issue (or something site
> specific). Do you know which component we should put this in for further
> investigation?

Looks to me to be a problem with the site - scrolling works fine for me unless my touch originates over the list of links after the top of the page, at which point it does nothing. A glance at the source shows that it does seem to have some scroll detection code that perhaps is failing and stopping scrolling altogether, but it's hard to tell (the source is minified and I'm not familiar with jQuery).

Now, whether it's failing because we have a platform problem I don't know, but this requires further investigation of the page before pinning it on platform I think.

Has anyone at least tried this in fennec, and/or Chrome for Android?

Comment 10

[Rachelle Yang [:ryang][[e-mail]]]

Hi Jeremy and Doyun,

Per comment9, would you please try on the scenario on Chrome/IE for Android,or other browser on FFOX?
Is it easily reproducible ?

Comment 11

[Doyun Kim]

I checked several browser with android device.( Opera, Chrome, Puffin, swing, Dolphin... )
It's not reproduced.
and I couldn't find any browser on Marketplace.
Would you please tell me the example?

and It's reproduced with Nightly simulator.(V2.0)
When it's reproduced, I can scroll with mouse wheel, but I can't scroll with mouse click.

Comment 12

[Rachelle Yang [:ryang][[e-mail]]]

Hi Chris, per comment11,

Do you have any idea we could make any progress on this bug ? Thank you very much.

Comment 13

[howie [:howie]]

Triage group: blocking as partner blocker.

Comment 14

[Chris Lord [:cwiiis]]

(In reply to Rachelle Yang [:ryang][[e-mail]] from comment #12)
> Hi Chris, per comment11,
> 
> Do you have any idea we could make any progress on this bug ? Thank you very
> much.

We need to determine that this isn't the site behaving badly vs. our code - They do have touch handlers, if they're calling preventDefault on a touchstart, that will disable scrolling. Can we verify that this isn't happening? If they are, this would be an evangelism issue... Though I'd be interested to know why it doesn't affect Chrome on Android (have we tried user-agent spoofing? Do we get the same markup/script as Chrome?)

If that isn't happening, it's reasonably likely to be an AsyncPanZoomController failure, so someone from gfx (botond, kats?) would need to help investigate that. Pre-emptively cc'ing Milan, but I think there's still work to be done to determine this isn't an issue with the site. I expect it is, especially if it affects the simulator.

Comment 15

[Changbin Park]

(In reply to Chris Lord [:cwiiis] from comment #14)
> We need to determine that this isn't the site behaving badly vs. our code -
> They do have touch handlers, if they're calling preventDefault on a
> touchstart, that will disable scrolling. Can we verify that this isn't
> happening? If they are, this would be an evangelism issue... Though I'd be
> interested to know why it doesn't affect Chrome on Android (have we tried
> user-agent spoofing? Do we get the same markup/script as Chrome?)
I have some digging on the site.
The site has flickable area (#article_flick) around the picture and it's controlled by a JS library named "Jindo" and shows different result between Firefox and Chrome.
In Firefox, event handler named fpOnTransitionEnd for "transitionend" which is located in 'jindo_mobile_component.js' is not called after canceled flick due to insufficient distance of flicking action.
AFAIK, it seems like a evangelism issue like you said.

Comment 16

[Changbin Park]

The pages contains example of a component from 'Jindo Mobile'
http://jindo.dev.naver.com/docs/jindo-mobile/archive/latest/demo/jindo.m.SlideFlicking/01.%20default.html
I tried the example with user-agent spoofing as Chrome34/Linux listed in User Agent Overrider(https://addons.mozilla.org/en-US/firefox/addon/user-agent-overrider/) extension, and it works fine.
So, I'm pretty sure it's content side issue.

Comment 17

[jeremy.kim.leo [:jeremykimleo]]

Thanks all, 

In comment 15, comment 16, this is evangelism issue.
so, let's move to WONTFIX

Comment 18

[Milan Sreckovic [:milan] (needinfo for best results)]

If it's evangelism, let's evangelize, rather than wontfix?

Comment 19

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

(In reply to Milan Sreckovic [:milan] from comment #18)
> If it's evangelism, let's evangelize, rather than wontfix?

But should we remove the blocking flag?

Comment 20

[Milan Sreckovic [:milan] (needinfo for best results)]

I would imagine we should.

Comment 21

[Changbin Park]

I report the bug to their project site.
http://dev.naver.com/projects/jindo/issue/86188

Comment 22

[Karl Dubost💡 :karlcow]

Closing as we are not working on Firefox OS anymore.