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.
Component: General → Preinstalled B2G Apps
Product: Boot2Gecko → Tech Evangelism
Version: unspecified → Trunk
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
Lisa please confirm that the developer has been notified. Thanks.
updates?? nothing changed
Assignee: lbrewster → hkirschner
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Priority: P1 → P2
Do we know any ETA?
Reproduced this on a Keon Geeksphone device with FFOS nightly build v1.2 Build ID 20131028225522 Platform Version 26.0a2
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.
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 . It might just require a server tweak on their side to get this fixed. : https://developer.mozilla.org/en-US/docs/Gecko_user_agent_string_reference#Firefox_OS
Also adding Hallvord here who worked with ad networks before on UA problems.
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...
(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?
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
Michelle, This bug has been open for over 4 months. Can you supply a fix by February 17th, please? Thank you.
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.