Error "the URL is not valid and cannot be loaded." appears after going to the awesome page and then invoking fennec to go to a URL through a commandline

VERIFIED FIXED in Firefox 11

Status

()

P1
normal
VERIFIED FIXED
7 years ago
2 years ago

People

(Reporter: nhirata, Assigned: kats)

Tracking

unspecified
Firefox 12
ARM
Android
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox11+ verified, firefox12 verified, fennec11+)

Details

Attachments

(2 attachments)

Created attachment 583609 [details]
screenshot

1) download http://people.mozilla.com/~nhirata/Perf/startup5.html 
2) adb push startup5.html /sdcard/download/
3) install build from : http://ftp.mozilla.org/pub/mozilla.org/mobile/tinderbox-builds/mozilla-central-android/1324041795/
4) adb shell am start -a android.intent.action.VIEW -n org.mozilla.fennec/.App -d file://sdcard/download/startup5.html#1324063534673
5) click on the URL bar to go to the awesome page
6) rerun : adb shell am start -a android.intent.action.VIEW -n org.mozilla.fennec/.App -d file://sdcard/download/startup5.html#1324063534673

Expected: Onload time displayed
Actual: 
Actual: error message "the URL is not valid and cannot be loaded."

Note:
Build 20111219; Samsung Nexus S; OS 2.3
Summary: Error appears → Error "the URL is not valid and cannot be loaded." appears after going to the awesome page and then invoking fennec to go to a URL through a commandline

Updated

7 years ago
Assignee: nobody → doug.turner
Duplicate of this bug: 713000
Priority: -- → P1

Comment 2

7 years ago
kats, probably related to :

https://hg.mozilla.org/integration/mozilla-inbound/raw-rev/b407ff123b6f


easily reproducible with:

1) launch fennec
2) go to the home screen
3) run:

   adb shell am start -a android.activity.VIEW -n org.mozilla.fennec_<user>/.App -d 'http://dougt.org'

Sub your username for <user> above
Assignee: doug.turner → bugmail.mozilla
Created attachment 584116 [details] [diff] [review]
Return correct object from openURI

Apparently my copy/paste skillz need work...
Attachment #584116 - Flags: review?(doug.turner)

Comment 4

7 years ago
Comment on attachment 584116 [details] [diff] [review]
Return correct object from openURI

Review of attachment 584116 [details] [diff] [review]:
-----------------------------------------------------------------

make sure that:

1) when fennec isn't running, clicking on a link in another app opens fennec (and of course loads the right url)
2) when fennec is running, but in the back ground, clicking on a link in another app opens fennec (and of course loads the right url)
Attachment #584116 - Flags: review?(doug.turner) → review+
Verified that clicking on a link to google that I typed up in the "Pen memo" app and selecting Fennec from the list of browsers opens google in Fennec in both scenarios (Fennec not running and Fennec in background).
Duplicate of this bug: 713557
Landed on m-i:

https://hg.mozilla.org/integration/mozilla-inbound/rev/3b1e6033d3ff
status-firefox11: --- → affected
Whiteboard: [inbound], [leave open after inbound merge]
Target Milestone: --- → Firefox 12
Attachment #584116 - Flags: approval-mozilla-aurora?
https://hg.mozilla.org/integration/mozilla-inbound/rev/b58836d3fa78

Backed out for causing Android m1 and m2 orange.
Whiteboard: [inbound], [leave open after inbound merge] → [leave open after inbound merge]
Comment on attachment 584116 [details] [diff] [review]
Return correct object from openURI

Investigating oranges
Attachment #584116 - Flags: approval-mozilla-aurora?
This patch was causing oranges with some strange errors in the log (see https://tbpl.mozilla.org/php/getParsedLog.php?id=8177298&tree=Try for an example, they are all pretty similar). The first error seems to be this line:

12-27 11:41:24.749 W/GraphicBufferMapper( 2080): lock(...) failed -16 (Device or resource busy)

snorp, this looks to be gralloc-related given the source I'm seeing at http://www.netmite.com/android/mydroid/2.0/frameworks/base/libs/ui/GraphicBufferMapper.cpp - any thoughts on why this might be happening? It might have to do with multiple windows and/or iframes give the tests that were failing and the nature of the patch.
(In reply to Kartikaya Gupta (:kats) from comment #10)
> This patch was causing oranges with some strange errors in the log (see
> https://tbpl.mozilla.org/php/getParsedLog.php?id=8177298&tree=Try for an
> example, they are all pretty similar). The first error seems to be this line:
> 
> 12-27 11:41:24.749 W/GraphicBufferMapper( 2080): lock(...) failed -16
> (Device or resource busy)
> 
> snorp, this looks to be gralloc-related given the source I'm seeing at
> http://www.netmite.com/android/mydroid/2.0/frameworks/base/libs/ui/
> GraphicBufferMapper.cpp - any thoughts on why this might be happening? It
> might have to do with multiple windows and/or iframes give the tests that
> were failing and the nature of the patch.

Kats - these errors seem to be happening in passing tests too. I see the in Tdhtml logs for example. I'm not sure they are the real cause of any orange.
status-firefox11: affected → ---
Target Milestone: Firefox 12 → ---
Duplicate of this bug: 713859
I see this error every time that I click a link in another app to open Aurora. If I click OK on the dialog and then refresh the link it open as expected.

build: Aurora 11.0a2 2011-12-27

Updated

7 years ago
status-firefox11: --- → affected
tracking-firefox11: --- → ?

Updated

7 years ago
Duplicate of this bug: 713993
Blocks: 712999
Duplicate of this bug: 713862
Duplicate of this bug: 714092
I'm trying to figure out why this is causing test failures. The tbpl logs don't have anything useful because for some reason the test runs the content/xslt/tests/mochitest/ set of tests after it fails during the content/xml/document/test/ set of tests, and all the logcat at the end of the logfile is from the XSLT tests, which passed just fine. Just looking at the SimpleTest output of the XML tests, it looks like it's dying while running the content/xml/document/test/test_bug691215.html test, so I tried to run that test in isolation by unhooking it from SimpleTest. Unfortunately, that also crashes my desktop FF (filed as bug 714232).

Regardless, I'm pretty sure that my patch isn't directly causing a failure, it's just uncovering a pre-existing bug somewhere by fixing window opening. I'll continue investigating, but probably won't get very far until the new year once I'm back from PTO.
See Also: → bug 714232
Duplicate of this bug: 711515
With the patch in bug 714234, the oranges go away.
Duplicate of this bug: 714314
Comment on attachment 584116 [details] [diff] [review]
Return correct object from openURI

Very much needed in Aurora
Attachment #584116 - Flags: approval-mozilla-aurora?
(In reply to Mark Finkle (:mfinkle) from comment #21)
> Kats - Why [leave open after inbound merge] ?

I thought the bug was supposed to stay open until the patch landed in aurora. Is that not the case?
(In reply to Kartikaya Gupta (:kats) from comment #23)
> (In reply to Mark Finkle (:mfinkle) from comment #21)
> > Kats - Why [leave open after inbound merge] ?
> 
> I thought the bug was supposed to stay open until the patch landed in
> aurora. Is that not the case?

Nope. We maek FIXED when a patch lands on m-c. We use the status-firefox11:affected and sometimes tracking-fennec:11 to track that a patch needs to move to aurora. Once the patch lands on aurora, we change to status-firefox11:fixed
Whiteboard: [leave open after inbound merge]
Target Milestone: --- → Firefox 11
tracking-firefox11: ? → +
And the TM is the branch where it first landed, so 12 rather than 11. So many knobs to twiddle!

https://hg.mozilla.org/mozilla-central/rev/8f2f34d90579
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Target Milestone: Firefox 11 → Firefox 12
Works perfect in latest Nightly build on Android. Marking as verified fixed. Thanks.
Status: RESOLVED → VERIFIED

Updated

7 years ago
status-firefox12: --- → verified

Comment 27

7 years ago
I hate to be the bearer of bad news, but the problem is still there, only the symptom went away. I don't get the "url is not valid" anymore but I still can't get external apps to load links when fennec's killed by android.

Ways to reproduce it:

1. Open fennec
2. kill fennec with ATK (advanced task killer) or wait for android to kill it
3. try to open a link with external app. Won't work.


I'm reopening this bug even though this looks to me more like bug 711515, which doesn't really seem a duplicate of this one
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
(In reply to Pedro Alves from comment #27)
> I hate to be the bearer of bad news, but the problem is still there, only
> the symptom went away. I don't get the "url is not valid" anymore but I
> still can't get external apps to load links when fennec's killed by android.

Yep, same here.

> I'm reopening this bug even though this looks to me more like bug 711515,
> which doesn't really seem a duplicate of this one

Yes, I think we should reopen bug 711515 instead.
It seems we have a conflict with Session Restore. Bug 711515 is a better bug for this issue.
Status: REOPENED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
See comment #22. This is making Aurora not usable as a browser, if you open lots of links from external apps.
Comment on attachment 584116 [details] [diff] [review]
Return correct object from openURI

[Triage Comment]
Mobile only and seems to at least partially resolve the external URI issue - approving for Aurora.
Attachment #584116 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Duplicate of this bug: 715167
Blocks: 713042
tracking-fennec: --- → 11+
Duplicate of this bug: 713042
Verified fixed on Nightly 12.0a1 (2012-01-18) and on Aurora 11.0a2.
Device: Samsung Galaxy S2 (Android 2.3.4)
Status: RESOLVED → VERIFIED
status-firefox11: fixed → verified
You need to log in before you can comment on or make changes to this bug.