Closed
Bug 796422
Opened 12 years ago
Closed 6 years ago
scrollIntoView() causes homescreen to be visible (B2G desktop/mulet)
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: ghtobz, Unassigned)
References
Details
(Whiteboard: [label:mozapps])
Attachments
(1 file)
|
(deleted),
image/png
|
Details |
The bustage in action
[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.
|
||
Updated•12 years ago
|
Component: Gaia → Gaia::Homescreen
|
||
Comment 3•10 years ago
|
||
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
|
||
Comment 4•10 years ago
|
||
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 → ---
|
|
||
Comment 5•10 years ago
|
||
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...
|
|
||
Comment 6•10 years ago
|
||
: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)
|
||
Comment 7•10 years ago
|
||
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)
|
|
||
Comment 8•9 years ago
|
||
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)
|
|
||
Comment 9•9 years ago
|
||
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)
|
||
Comment 12•9 years ago
|
||
Still happen with Mulet.
|
|
||
Updated•9 years ago
|
Summary: scrollIntoView() causes homescreen to be visible (B2G desktop) → scrollIntoView() causes homescreen to be visible (B2G desktop/mulet)
|
|
||
Comment 13•9 years ago
|
||
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
|
|
||
Comment 14•9 years ago
|
||
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)
|
||
Comment 15•9 years ago
|
||
(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 16•9 years ago
|
||
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)
|
|
||
Updated•9 years ago
|
Component: DOM: Content Processes → Layout
|
||
Comment 17•9 years ago
|
||
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)
|
|
||
Comment 18•9 years ago
|
||
It looks like Olli has taken a look at this bug. I'm clearing the needinfo request flag.
| Comment hidden (offtopic) |
| Comment hidden (offtopic) |
|
||
Comment 21•9 years ago
|
||
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)
|
|
||
Comment 22•9 years ago
|
||
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)
|
|
||
Updated•9 years ago
|
Assignee: squibblyflabbetydoo → nobody
|
||
Comment 24•6 years ago
|
||
Mass closing as we are no longer working on b2g/firefox os.
Status: NEW → RESOLVED
Closed: 10 years ago → 6 years ago
Resolution: --- → WONTFIX
|
|
||
Comment 25•6 years ago
|
||
Mass closing as we are no longer working on b2g/firefox os.
|
|
||
Updated•6 years ago
|
Flags: needinfo?(tnikkel)
You need to log in
before you can comment on or make changes to this bug.
Description
•