Closed
Bug 855224
Opened 13 years ago
Closed 7 years ago
[Buri][Browser][DOM]Change source/URL of two frames fails
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
RESOLVED
WONTFIX
| blocking-b2g | - |
People
(Reporter: sync-1, Unassigned)
References
()
Details
Attachments
(2 files)
screenshot
AU_LINUX_GECKO_ICS_STRAWBERRY_V1.01.00.01.19.044
Firefox os v1.0.1
Mozilla build ID: 20130319070203
+++ This bug was initially created as a clone of Bug #427558 +++
Created an attachment (id=371855)
screenshot
DEFECT DESCRIPTION:
[Browser][DOM]Change source/URL of two frames fails
REPRODUCING PROCEDURES:
1.connect to VAL-TEST wifi or its wifi hotspot
2.goto http://wapmail.tcl-ta.com/js_test/frame/source.html
3.click change frame source,it shows just the left frame source changed,refer to screenshot1---KO
EXPECTED BEHAVIOUR:
The left frame and right frame source should both changes.
ASSOCIATE SPECIFICATION:
TEST PLAN REFERENCE:B2G-1860
TOOLS AND PLATFORMS USED:
USER IMPACT:
REPRODUCING RATE:5/5
For FT PR, Please list reference mobile's behavior:
For Telsa FCA,the source of two frames are both changed.
The code of the webpage on step2.
<html>
<frameset id="myFrameset" cols="50%,50%">
<frame id="leftFrame" src="frame_src.htm">
<frame id="rightFrame" src="frame_a.htm">
</frameset>
</html>
++++++++++ end of initial bug #427558 description ++++++++++
CONTACT INFO (Name,Phone number):
DEFECT DESCRIPTION:
REPRODUCING PROCEDURES:
EXPECTED BEHAVIOUR:
ASSOCIATE SPECIFICATION:
TEST PLAN REFERENCE:
TOOLS AND PLATFORMS USED:
USER IMPACT:
REPRODUCING RATE:
For FT PR, Please list reference mobile's behavior:
|
||
Comment 1•13 years ago
|
||
|
|
||
Comment 2•13 years ago
|
||
|
|
||
Updated•13 years ago
|
blocking-b2g: --- → tef?
Flags: needinfo?(bfrancis)
|
|
||
Comment 3•13 years ago
|
||
It about iframe change. Who can help?
|
||
Comment 4•13 years ago
|
||
(In reply to sync-1 from comment #0)
> 2.goto http://wapmail.tcl-ta.com/js_test/frame/source.html
I was unable to reach this web page when trying to reproduce this bug.
Flags: needinfo?(bfrancis)
|
|
||
Comment 5•13 years ago
|
||
1.Code of http://wapmail.tcl-ta.com/js_test/frame/source.html：
<html>
<frameset id="myFrameset" cols="50%,50%">
<frame id="leftFrame" src="frame_src.htm">
<frame id="rightFrame" src="frame_a.htm">
</frameset>
</html>
2.Code of frame_src.htm：
<html>
<head>
<script type="text/javascript">
function newSrc()
{
parent.document.getElementById("leftFrame").src="http://wap.yahoo.com";
parent.document.getElementById("rightFrame").src="http://sina.cn";
}
</script>
</head>
<body>
<input type="button" onclick="newSrc()" value="Change frame source" />
</body>
</html>
3.Code of frame_a.htm：
<html>
<body bgcolor="#66CCFF">
<h3>Frame A</h3>
</body>
</html>
|
||
Comment 6•13 years ago
|
||
What is the user impact of this bug?
Flags: needinfo?(sync-1)
Whiteboard: [tef-triage]
|
|
||
Comment 7•13 years ago
|
||
For some websites maybe divided into serval frames, and each frame has
different url. Our browser should support this.
Flags: needinfo?(sync-1)
|
||
Comment 8•13 years ago
|
||
Jason can you confirm this & also weigh in on how many top sites would hit issues with something like this?
Keywords: qawanted
QA Contact: jsmith
|
|
||
Updated•13 years ago
|
Flags: needinfo?(jsmith)
|
|
||
Comment 9•13 years ago
|
||
I'll look into this for reproducibility.
As for how likely this would be used, I don't know. Let me redirect that question over to Jonas to see what he thinks and cc some DOM folks for some opinions here.
Flags: needinfo?(jsmith)
|
|
||
Comment 10•13 years ago
|
||
Jonas - Do you how likely the use case stated in the bug can happen in the web? Is it likely? Unlikely?
We are trying to figure out a blocking decision here, so your input would be greatly appreciated.
Flags: needinfo?(jonas)
|
|
||
Comment 11•13 years ago
|
||
Unable to verify on Buri device since the blocking Bug 869246
|
|
||
Updated•13 years ago
|
Component: Gaia::Browser → DOM
Product: Boot2Gecko → Core
Version: unspecified → Trunk
|
|
||
Updated•13 years ago
|
|
|
||
Comment 12•13 years ago
|
||
I reproduced this issue on a 1.01 build on 5/13. This test case works on Desktop Firefox & FxAndroid, but fails on FF OS.
Flags: needinfo?(jonas)
Keywords: qawanted
|
|
||
Comment 13•13 years ago
|
||
Justin - Any thoughts on this? My guess is that this bug would be happening with mozbrowser, right?
Flags: needinfo?(justin.lebar+bug)
|
||
Comment 14•13 years ago
|
||
Using http://jds2501.github.io/webapi-permissions-tests/source.html
> parent.document.getElementById("leftFrame").src="http://wap.yahoo.com";
> parent.document.getElementById("rightFrame").src="http://sina.cn";
It appears to redirect itself, and then redirects the right frame. I would not be surprised if that's undefined behavior.
In Firefox on desktop, I get a blank white page on the left and then Sina on the right. That's what's happening on the phone according to comment 0, right? When I try it in Chrome, the button stays on the left, and Sina appears on the right; again, this is not what I understand the expected result from comment 0 to be. In neither case does wap.yahoo.com load into the left frame.
Am I missing something?
Flags: needinfo?(justin.lebar+bug)
|
|
||
Comment 15•13 years ago
|
||
Got more information of use of frames - this is not a common use case for the mobile web at all. That aligns why QA has never seen this in top site testing, because mobile sites do not use frames such as what is seen in this test case commonly.
I'm arguing this is a non-blocker.
|
|
||
Comment 16•13 years ago
|
||
(In reply to Justin Lebar [:jlebar] from comment #14)
> Using http://jds2501.github.io/webapi-permissions-tests/source.html
>
> > parent.document.getElementById("leftFrame").src="http://wap.yahoo.com";
> > parent.document.getElementById("rightFrame").src="http://sina.cn";
>
> It appears to redirect itself, and then redirects the right frame. I would
> not be surprised if that's undefined behavior.
>
> In Firefox on desktop, I get a blank white page on the left and then Sina on
> the right. That's what's happening on the phone according to comment 0,
> right?
yes, the FF OS browser should performance like the desktop Firefox.
|
|
||
Comment 17•13 years ago
|
||
> yes, the FF OS browser should performance like the desktop Firefox.
I don't understand why we care if a page which navigates itself and then performs some action behaves differently in desktop versus b2g. As you can see, this page already behaves differently in two different desktop browsers.
This is an edge case of an edge case, as far as I can tell.
To be clear: I definitely wouldn't hold the release for this unless data comes up showing that this is affecting more sites that it seems so far.
However I definitely think that we should try to behave like desktop. Navigation is an area where pages do *a lot* of crazy shit that makes absolutely no sense. So deviating from what Firefox desktop does is going to break an unknown amount of pages.
And it's not at all rare that different behavior in a different browser is cancelled out by different behavior in another area. So I would be worried about using the logic of "other browsers doesn't do the same thing so people probably don't depend on this".
But if desktop firefox behaves in a timing dependent way, and Firefox OS triggers a different behavior because we're running on a slower device or over a slower connection, then I don't think there's much we can do.
So, in short, I don't think we should worry about this for v1.0.1. But it'd be good to look into why we behave differently from desktop since differences in navigation behavior sounds very scary.
|
|
||
Comment 19•13 years ago
|
||
I agree we should not hold the 1.0.1 release because of this.
|
||
Comment 20•13 years ago
|
||
Not blocking it based on QA comment and investigation from comment#18#17
blocking-b2g: tef? → -
|
|
||
Updated•13 years ago
|
Whiteboard: [tef-triage]
|
||
Comment 21•7 years ago
|
||
Closing as we are not working on Firefox OS anymore.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
|
Assignee | |
Updated•7 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•