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

Status: RESOLVED FIXED

(Tech Evangelism Graveyard :: Preinstalled B2G Apps, defect, P2)

Description

[Jaime Vega]

Attachment: 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.

Comment 1

[Karen Ward [:kward]]

Lisa please confirm that the developer has been notified. Thanks.

Comment 2

[joseenrique.alvarezfernandez]

Any updates????

Comment 3

[Jaime Vega]

updates?? nothing changed

Comment 4

[Jaime Vega]

Do we know any ETA?

Comment 5

[Elisa Helton]

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

Build ID
20131028225522

Platform Version
26.0a2

Comment 6

[Elisa Helton]

Response from [e-mail]: 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.

Comment 7

[Steve Mummey]

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.

Comment 8

[:Harald Kirschner :digitarald]

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

Comment 9

[:Harald Kirschner :digitarald]

Also adding Hallvord here who worked with ad networks before on UA problems.

Comment 10

[Steve Mummey]

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...

Comment 11

[Hallvord R. M. Steen [:hallvors]]

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..?

Comment 12

[Hallvord R. M. Steen [:hallvors]]

(BTW Harald was probably thinking about bug 936454 which may very well be relevant here - will look into that shortly)

Comment 13

[Hallvord R. M. Steen [:hallvors]]

Attachment: 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

[Elisa Helton]

Reproduced on Keon Geeksphone device v1.2 build 20131028225522

Michelle, can you please provide a date for when this bug will get resolved?

Comment 15

[Nicole Fong]

Michelle,

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

Comment 16

[Nicole Fong]

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

Changing status to "Resolved"

Comment 17

[Hallvord R. M. Steen [:hallvors]]

Nicole Fong: did you test with the attached test case as well?
Just checking ;-)