Closed Bug 796422 Opened 12 years ago Closed 6 years ago

scrollIntoView() causes homescreen to be visible (B2G desktop/mulet)

Categories

(Core :: Layout, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: ghtobz, Unassigned)

References

Details

(Whiteboard: [label:mozapps])

Attachments

(1 file)

[GitHub issue by brendandahl on 2012-07-24T16:46:04Z, https://github.com/mozilla-b2g/gaia/issues/2745] Using an app with the following causes part of the homescreen to be shown at the bottom. After viewing this all following apps viewed also are displayed incorrectly. Screenshot: http://people.mozilla.com/~bdahl/snps/b2g_scroll_bug.png Test: ```html <!DOCTYPE html> <html> <head> <script type="text/javascript"> window.addEventListener('load', function webViewerLoad(evt) { document.getElementById('one').scrollIntoView(); }); </script> </head> <body> <div id="one">One</div> </body> </html> ```
[GitHub comment by nhirata on 2012-07-24T17:01:03Z] is #2414 related?
[GitHub comment by brendandahl on 2012-07-24T17:29:36Z] It could be, though this bug doesn't seem to affect the homescreen.
Component: Gaia → Gaia::Homescreen
Blocks: 844868
This seems to have been fixed at some point. I just tried with the test case and it appeared to work.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
I still see this on b2g desktop. I imagine it's a Gecko issue, since this works on a real device.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached image The bustage in action —
This is what the music app looks like on b2g-desktop with the patch from bug 1147173. I wouldn't care so much except that it breaks a bunch of marionette tests...
:kats, I'm told you might know about this. Any ideas? I can try to write a new reduced testcase if the one in comment 0 isn't helpful.
Flags: needinfo?(bugmail.mozilla)
Blocks: 1147173
I don't have any recent experience with b2g desktop so I don't know what the scrollframe/layer tree structure looks like there. From the screenshot alone it looks like there must be a scrollframe that contains the app and so is scrolling the app out of view in order to align the requested element to the top of the screen. That it doesn't happen on-device means that's likely just an artifact of b2g-desktop being an imperfect simulation. For example, do you know if b2g desktop uses multiprocess browsing? I know it doesn't use the gonk widget code at least. I doubt this is related to APZ code directly because scrollIntoView is basically equivalent to a scrollTo from the APZ point of view. If this is blocking you I can look into it but likely not until next week. Please re-needinfo me if you would like me to look into it.
Flags: needinfo?(bugmail.mozilla)
No longer blocks: 1147173
Blocks: 1166006
Ok, I've split out the code I was having troubles with into bug 1166006. It'd still be nice to get this fixed in Gecko so we can land that bug, but it's less-urgent now. Regarding comment 7, it's been a while since I've looked at it, but I want to say that b2g desktop is single-process, which might be part of the problem here...
Flags: needinfo?(bugmail.mozilla)
If B2G desktop is single process then my theory is that the scrollIntoView implementation doesn't stop at the app boundary but keeps walking into the parent app which is probably not good. Based on that this likely belongs in the DOM component.
Component: Gaia::Homescreen → DOM: Content Processes
Flags: needinfo?(bugmail.mozilla)
Product: Firefox OS → Core
Summary: scrollIntoView() causes homescreen to be visible → scrollIntoView() causes homescreen to be visible (B2G desktop)
Blocks: 1194228
This break the tests I have in bug 1194228.
Status: REOPENED → NEW
No longer blocks: 1194228
Still happen with Mulet.
Summary: scrollIntoView() causes homescreen to be visible (B2G desktop) → scrollIntoView() causes homescreen to be visible (B2G desktop/mulet)
Tentatively taking this so it's on my radar. I'm not an expert on DOM stuff, but it'd be nice to get this bug fixed, and I can probably find some people to annoy until I know where to look. I don't expect to get to this until mid-December though, since I'm busy putting out fires elsewhere.
Assignee: nobody → squibblyflabbetydoo
Status: NEW → ASSIGNED
Blocks: 1218520
Julie, This bugs as prevent us from testing. It is still in Mulet. Do you think you can get somebody from platform to help Jim to fix it? Thanks
Flags: needinfo?(jmccracken)
No longer blocks: 1218520
(In reply to Hubert Figuiere [:hub] from comment #14) > Julie, > > This bugs as prevent us from testing. It is still in Mulet. Do you think you > can get somebody from platform to help Jim to fix it? > > Thanks I'll try to get it assigned. Should I try to find someone on the DOM team?
comment 9 sounds like valid here, and the relevant code seems to be around http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#3555 We should not cross app or docshell type boundaries there I think. Picking up random layout dev for the question: do we have a form of GetCrossDocParentFrame which does cross normal iframe boundaries, but doesn't cross app boundaries?
Flags: needinfo?(dholbert)
Component: DOM: Content Processes → Layout
I'm not familiar with GetCrossDocParentFrame, so your guess/MXR-research would be as good as mine. :) I'll tag tn to see if he has any thoughts on the question in comment 16, though, as he's at least touched the GetCrossDocParentFrame documentation (albeit in 2010).
Flags: needinfo?(dholbert) → needinfo?(tnikkel)
It looks like Olli has taken a look at this bug. I'm clearing the needinfo request flag.
Not sure if we need a new version of GetCrossDocParentFrame just for this case. So if there is no parent, and we have to call GetCrossDocParentFrame in PresShell::ScrollFrameRectIntoView then that means we will be crossing into a new document. At that point we should just check if we are crossing an app boundary. Not sure what the recipe is for that exactly, but the ingredients should be there: parent will be the frame of the iframe element. So if someone wants to do that, or point me at the code to determine "app-ness".
Flags: needinfo?(tnikkel)
nsPIDOMWindow has GetScriptableParent which returns 'this' when at the app boundary. Or you may want to use docshell: docShell->GetIsBrowserOrApp() should tell if you're at the topmost app level docshell.
Flags: needinfo?(tnikkel)
Blocks: 1180516
Unassigning myself. Should we WONTFIX this?
Status: ASSIGNED → NEW
Assignee: squibblyflabbetydoo → nobody
Mass closing as we are no longer working on b2g/firefox os.
Status: NEW → RESOLVED
Closed: 10 years ago6 years ago
Resolution: --- → WONTFIX
Mass closing as we are no longer working on b2g/firefox os.
Flags: needinfo?(tnikkel)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: