1074110 - In m.naver.com, some links, panning, and flicking do not work.

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: General, defect, P2)

Description

[Youngwoo Jo]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20140925030203

Steps to reproduce:

1. Open "m.naver.com" page in browser app
2. Open any article in the list of "m.naver.com" page.
3. If it's an article, the linked page includes "관련뉴스" area and "랭킹뉴스" area in the below of the page, in Korean.
4-1. Vertically panning(or flicking) on the area("관련뉴스").
4-2. Horizontally panning(or flicking) on the area("관련뉴스").
4-3. Click on any link of the sequence of 3 pictures("관련뉴스").
4-4. Vertically panning(or flicking) on the area("랭킹뉴스").
4-5. Horizontally panning(or flicking) on the area("랭킹뉴스").
4-6. Click on any link of the list of "랭킹뉴스".


Actual results:

4-1. Sometimes, vertical scroll does not work by panning or flicking.
4-2. The content of the area is not changed by panning horizontally or flicking.
4-3. The links do not work.
4-4. Same as 4-1.
4-5. Same as 4-2.
4-6. Same as 4-3.


Expected results:

4-1. Vertical scroll should always work by panning or flicking.
4-2. The area should be changed horizontally when the area is being panned or being flicked horizontally.
4-3. The links should always work, whenever they are clicked.
4-4. Same as 4-1.
4-5. Same as 4-2.
4-6. Same as 4-3.

Comment 1

[Youngwoo Jo]

Attachment: related_news.png

This screen shot is a region of "관련뉴스". The red rectangle is scrollable horizontally. but it works incorrectly.
And also if you start panning from the red rectangle, vertical scroll does not work.
And in this case, the links does not work.

Comment 2

[Youngwoo Jo]

Attachment: ranking_news.png

This picture is a screenshot of "랭킹뉴스", in Korean. The red rectangle has the same problem with the previous related_news.png.

Comment 3

[Youngwoo Jo]

This issue happens in flame v2.0.
It might be a content issue, but I'm not sure.
So I think we have to decide how to handle this issue, after the root cause is analyzed.

Comment 4

[Youngsu Rho]

This site handles the touch events directly in the issue regions.
In case of the issue case, this site looks like that it blocks the touch event.

The cause might be a problem of sequence of touch events or a abnormal processing of this web page.
However currently I'm not sure which is the root cause.

This is my simple analysis.
 1. SwipeCommon receives touch events and decide the next proper action by its own state machine.
    (jindo.mobile.component.js:jindo.m.SwipeCommon)
 2. jindo.m.SwipeCommon.prototype._preventSystemEvent is called in order to decide if it rejects the current touch event.
 3. But. SwipeCommon does not define the issue case, so it rejects the touch event. <-point

 You can check the event normal operation with the following exceptions.
   > jindo.$Event.prototype.stop = function (f) { return this; };


Reproducible device
1. Flame 
2. Android Firefox Browser (Reproduce low than FxOS)

Comment 5

[Youngwoo Jo]

This issue has 3 sub issues.
- vertical scroll
- horizontal scroll
- link

I confirmed that the horizontal scroll issue is caused by a user-agent string.
It's normal, when I used android firefox browser user-agent string, "Mozilla/5.0 (Android; Mobile; rv:32.0) Gecko/32.0 Firefox/32.0".

So, ignore the horizontal scroll issue.

Comment 6

[Youngwoo Jo]

I confirmed that the vertical scroll issue and the link issue are resolved by the test code by Youngsu.
 - I added the test code to the web page, via the console editor.
   > jindo.$Event.prototype.stop = function (f) { console.log("exception"); return this; };

So I think it's certain that the remaining two issues are related to the analysis by Youngsu.

Comment 7

[Youngwoo Jo]

Link in flame works fine.
The link issue looks like that it happens only in my own device.

So I compared the test on flame and on my own device.
The difference is "touchmove" event.
 - My own device generates "touchmove" events even tough I touched very short.
 - But flame does not generate "touchmove" event in case of the normal short touch.
I think this result is by the sensitivity and DPI.
When "touchmove" event is fired, the webpage makes the link blocked according to the above analysis by Youngsu.

So I think customization of touchmove event is needed in the device or gecko.

Comment 8

[BMO Automation]

Firefox OS is not being worked on