[Leo] When scrolling down in AccuWeather there is a big blank space that you cannot scroll up and down

RESOLVED FIXED

Status

Tech Evangelism
Preinstalled B2G Apps
P2
major
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: Jaime Vega, Assigned: devomanager, NeedInfo)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Created attachment 804688 [details]
2013-09-13-16-55-40.png

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 (Beta/Release)
Build ID: 20130814063812

Steps to reproduce:

I downloaded the AccuWeather App and scroll down until the end of the page.



Actual results:

When I wanted to scroll up I could not if I try from the blanck part, but it works if scroll it from the OS icons.


Expected results:

I do not know why there is a blank space  and I should not get stacked when trying to scroll up and down.

Updated

4 years ago
Blocks: 868100
Component: General → Preinstalled B2G Apps
Product: Boot2Gecko → Tech Evangelism
Version: unspecified → Trunk

Updated

4 years ago
Assignee: nobody → lbrewster
Summary: When scrolling down in AccuWeather there is a big blank space that you cannot scroll up and down → [Leo] When scrolling down in AccuWeather there is a big blank space that you cannot scroll up and down
(Reporter)

Updated

4 years ago
Severity: normal → major
Priority: -- → P1

Comment 1

4 years ago
Lisa please confirm that the developer has been notified. Thanks.
Flags: needinfo?(lbrewster)
Any updates????
(Reporter)

Comment 3

4 years ago
updates?? nothing changed

Updated

4 years ago
Assignee: lbrewster → hkirschner
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: P1 → P2
(Reporter)

Comment 4

4 years ago
Do we know any ETA?

Comment 5

4 years ago
Reproduced this on a Keon Geeksphone device with FFOS nightly build v1.2

Build ID
20131028225522

Platform Version
26.0a2

Comment 6

4 years ago
Response from Devomanager@accuweather.com: Ad did not load. That is dependent on ad-servers (not under our control).


This bug is unique from 911423 (which refers to the blank space at the bottom of most pages) because it refers to the problem of not being able to scroll. Once the user scrolls down this far, they cannot scroll back up to the top of the page, forcing the user to kill the app in order to get back to the Accuweather homepage.

We need the scrolling issue fixed.

Updated

4 years ago
Flags: needinfo?(lbrewster)

Comment 7

4 years ago
This regrettably is not unique from the other blank space issues. They are all related to advertising. Our advertising operations partner, Amobee, has relationships with hundreds of ad networks worldwide, who we use to monetize our global audience. From my experience, many of the ad creatives are not coded with a "parent site" in mind and when they are loaded into a parent site, the lack of quality coding impacts our site. This is challenging for us as a company because we need to be able to to monetize our traffic and since most agencies and buyers are not yet ready to shift their ad spends toward mobile, we are at the mercy of the ad networks. I wish we had a better answer this, but unfortunately we don't.
What is the "parent side" on this case? The app runs in its own browser and is not wrapped in any way. In contrast to running in the browser you don't have a user tracking that would tell the ad provider which sites the user also visited; which means its tracking is solely based on Accuweather usage.

I'd guess that Amobee does some unexpected user agent sniffing that fails badly, resulting into a black screen. Even without user details, Amobee should serve generic ads and not blank space. Can check on your side with them, sharing the details about the Firefox OS user agent [1]. It might just require a server tweak on their side to get this fixed.

[1]: https://developer.mozilla.org/en-US/docs/Gecko_user_agent_string_reference#Firefox_OS
Flags: needinfo?(mummey)
Also adding Hallvord here who worked with ad networks before on UA problems.
Flags: needinfo?(hsteen)

Comment 10

4 years ago
Sorry, I was referring to AccuWeather.com as the parent site. Firefox OS is not the only place this occurs.

We've been seeing full HTML pages injected into ad slots recently. Having one page with 2 sets of html, head and body tags usually doesn't work in a browser.

Many of the blank 300x250 ads are coming from Google's AdSense network. They use a series of nested iFrames to display ads and even though the DOM is structured properly, the ad will not display. I've been trying to find a solution to this for a few days but have not had any success. I'm open to ideas...
Flags: needinfo?(mummey)
I've had a look at this both on device (Geeksphone) and simulator, and both with Accuweather installed as an app and just going to m.accuweather.com. I see a single empty ad-sized area above the footer text, apparently this is the markup:

    <div class="bot-ad">
        <script type="text/javascript">
document.write("<scr" + "ipt type=\"text/javascript\"><!--\n"+"google_ad_client = \"ca-pub-5771594739411148\";\n"+"google_ad_width = \"300\";\n"+"google_ad_height =\"250\";\n"+"google_ad_slot= \"5977634367\";\n"+"//-->\n"+"</scr" + "ipt>\n"+"<scr" + "ipt type=\"text/javascript\" src=\"http://pagead2.googlesyndication.com/pagead/show_ads.js\">\n"+"</scr" + "ipt>\n");
</script><script type="text/javascript"><!--
google_ad_client = "ca-pub-5771594739411148";
google_ad_width = "300";
google_ad_height ="250";
google_ad_slot= "5977634367";
//-->
</script>
<script type="text/javascript" src="http://pagead2.googlesyndication.com/pagead/show_ads.js">
</script><ins style="display:inline-table;border:none;height:250px;margin:0;padding:0;position:relative;visibility:visible;width:300px;background-color:transparent"><ins id="aswift_1_anchor" style="display:block;border:none;height:250px;margin:0;padding:0;position:relative;visibility:visible;width:300px;background-color:transparent"><iframe marginwidth="0" marginheight="0" vspace="0" hspace="0" allowtransparency="true" onload="var i=this.id,s=window.google_iframe_oncopy,H=s&amp;&amp;s.handlers,h=H&amp;&amp;H[i],w=this.contentWindow,d;try{d=w.document}catch(e){}if(h&amp;&amp;d&amp;&amp;(!d.body||!d.body.firstChild)){if(h.call){setTimeout(h,0)}else if(h.match){try{h=s.upd(h,i)}catch(e){}w.location.replace(h)}}" id="aswift_1" name="aswift_1" style="left:0;position:absolute;top:0;" frameborder="0" height="250" scrolling="no" width="300"></iframe></ins></ins>

    </div>

It looks like an empty IFRAME - if there are more of those, it might explain scrolling problems..?
Flags: needinfo?(hsteen)
(BTW Harald was probably thinking about bug 936454 which may very well be relevant here - will look into that shortly)
Created attachment 8338460 [details]
916294.htm - test case

There is backend sniffing going on at googleads.g.doubleclick.net - so that part looks very similar to 936454 indeed. However, the sniffing seems like a red herring - it seems like a sub-optimal implementation on our part if an empty IFRAME picks up scroll/swipe actions and this prevents you from scrolling the main page?!? The attached file demonstrates this when installed as an "app" in the emulator, but I could not reproduce w/ Firefox OS 1.1 on device. Maybe there's a fix somewhere?

Comment 14

4 years ago
Reproduced on Keon Geeksphone device v1.2 build 20131028225522

Michelle, can you please provide a date for when this bug will get resolved?
Assignee: hkirschner → devomanager
Flags: needinfo?(devomanager)

Comment 15

4 years ago
Michelle,

This bug has been open for over 4 months.  Can you supply a fix by February 17th, please?  Thank you.

Comment 16

4 years ago
Was NOT able to reproduce on Inari v1.1 and Peak v1.3

Changing status to "Resolved"
Status: ASSIGNED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Nicole Fong: did you test with the attached test case as well?
Just checking ;-)
You need to log in before you can comment on or make changes to this bug.