Closed Bug 712761 Opened 13 years ago Closed 13 years ago

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

Categories

(Firefox for Android Graveyard :: General, defect, P1)

ARM
Android
defect

Tracking

(firefox11+ verified, firefox12 verified, fennec11+)

VERIFIED FIXED
Firefox 12
Tracking Status
firefox11 + verified
firefox12 --- verified
fennec 11+ ---

People

(Reporter: nhirata, Assigned: kats)

References

Details

Attachments

(2 files)

Attached image 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
Assignee: nobody → doug.turner
Priority: -- → P1
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
Apparently my copy/paste skillz need work...
Attachment #584116 - Flags: review?(doug.turner)
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).
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.
Target Milestone: Firefox 12 → ---
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
Blocks: 712999
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: → 714232
With the patch in bug 714234, the oranges go away.
See Also: 714232
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
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
Closed: 13 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
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
Closed: 13 years ago13 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+
Blocks: 713042
tracking-fennec: --- → 11+
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
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: