Open Bug 1004992 Opened 12 years ago Updated 3 years ago

Failure (NS_ERROR_MALFORMED_URI) [nsIWebNavigation.loadURI] with today's build

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
All
macOS
Type:
defect

Tracking

(firefox30 unaffected, firefox31- affected, firefox32 unaffected)

Tracking Flags:
Tracking Status
firefox30 --- unaffected
firefox31 - affected
firefox32 --- unaffected

People

(Reporter: AndreeaMatei, Unassigned)

References

Details

(Whiteboard: [mozmill])

Attachments

(1 file)

ScreenShot
110.10 KB, image/png
Details
Attached image ScreenShot —
Something went wrong in today's build for Aurora, at least on OS X (I've seen Windows and Linux are not up yet). I've seen a merge was done recently. Our mozmill testruns fail with: Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIWebNavigation.loadURI], please see bug 1004986.
No longer blocks: 1004986
Depends on: 1004986
Blocks: 1004986
No longer depends on: 1004986
Sorry about the dependency noise. I think this might be related to about:home, the page existed in a previous build, today is not. Francesco, could you have a look here? Thanks!
Flags: needinfo?(francesco.lodolo)
Hm, the only l10n change we had here was for bug 1002442 but that landed on Apr 29th, so not sure if this is related when it started today. Maybe something on the build system side has also been changed?
I was pointing to the same bug https://hg.mozilla.org/releases/l10n/mozilla-aurora/zh-CN/rev/7cd8d760fea6 What is the value of browser.startup.homepage in about:config?
Flags: needinfo?(francesco.lodolo)
This value of the property only got reverted to a state we had before. So how could this become a problem?
That one is correct: http:start.firefoxchina.cn What I see different today is the about:home / about:newtab pages that are like in the screenshot, which we're using when closing all tabs (we open a new tab). In yesterday's build, those pages exist.
Just downloaded firefox-31.0a2.zh-CN.mac.dmg, created a new profile and the right page shows up :-\
(In reply to Francesco Lodolo [:flod] from comment #6) > Just downloaded firefox-31.0a2.zh-CN.mac.dmg, created a new profile and the > right page shows up :-\ Correction: the first page loads fine, same if I use alt+home. about:newtab (cmd+T) and about:home show that error page. Is zh-CN the only one with this problem on Aurora? It seems strange.
Well, I checked Aurora de, zh-tw, mr, ru for example and they work fine. Not sure about all the rest, we automatically run on 4 locales, zh-CN is one of them.
about:app-manager is broken, too.
I'm moving this over into gecko, this dies somewhere in browser.webNavigation, which is docshell code. I'm hoping someone there can debug the problem. I've already did devtools, and the urls for about about:newtab and about:app-manager look totaly sane.
Assignee: shaohua.wen → nobody
Component: zh-CN / Chinese (Simplified) → Document Navigation
Product: Mozilla Localizations → Core
QA Contact: shaohua.wen
Andreea can you please quickly check if beta and/or nightly are also affected?
tracking-firefox31: --- → ?
Whiteboard: [mozmill]
Those are not affected, checked Nightly on OS X from today and the last beta build 30.0b1 fron April 29th.
Can someone provide some clear steps to reproduce here? What URI string is being passed in when the error happens? Is mozmill required, or is there a way to reproduce the issue without mozmill? Typically, NS_ERROR_MALFORMED_URI just means that the string passed in is so bogus we can't parse it as a URI at all...
Thanks for looking into this: Here's what I did, on mac: Download http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-aurora-l10n/firefox-31.0a2.zh-CN.mac.dmg Create empty dir start up the firefox -profile /tmp/profile Apple-t for new tab, or manually enter about:newtab. Or go to the devtools to open the app manager. Both come back with the broken URL screen. I've dug down with chrome remote debugging up to the point where the code path leaves the xbl binding, and dives into webNavigation, and the url was just "about:newtab" and "about:app-manager". Just as I expected.
[Exception... "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIWebNavigation.loadURI]" nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)" location: "JS frame :: chrome://global/content/bindings/browser.xml :: loadURIWithFlags :: line 148" data: no] and tabbrowser.xml:1642 show up in the browser console.
So some data. If I open a browser scratchpad in an affected build, and do this: Cc["@mozilla.org/network/io-service;1"]. getService(Ci.nsIIOService). newURI("about:newtab", null, null) this works. If I do this: Cc["@mozilla.org/network/io-service;1"]. getService(Ci.nsIIOService). newChannel("about:newtab", null, null) it throws NS_ERROR_MALFORMED_URI. The key difference is that the former doesn't check whether there is an about module for the URI. The latter does. That suggests that browser/components/about/AboutRedirector.cpp is not being registered in the relevant builds for some reason. I also checked that directly loading chrome://browser/content/newtab/newTab.xul works, and it does. So the issue is in fact with the about redirector.
Also: Cc["@mozilla.org/network/protocol/about;1?what=newtab"] returns undefined. It shouldn't.
I cannot reproduce this on Ubuntu 12.04 nor Windows 8.1 with the zh-CN build. I can only reproduce this on Mac OSX. So at least this is isolated to this platform. Further testing has revealed that I can reproduce this problem on the following pages: * about:home * about:newtab * about:sessionrestore The following about pages appear to be unaffected: * about: * about:addons * about:blank * about:buildconfig * about:config * about:credits * about:memory * about:plugins * about:support * about:telemetry I'm now going to test to see which locales are impacted.
From the console of an affected build: Native module at path '/Volumes/Aurora/FirefoxAurora.app/Contents/MacOS/browser/components/libbrowsercomps.dylib' doesn't export symbol `NSModule`. This must be some sort of build/repack issue?
Component: Document Navigation → Build Config
I don't have a mac handy to test with. Can anyone run `nm -g` on librowsercomps.dylib and report the export names?
Flags: needinfo?(mh+mozilla)
kochbuch:mozilla-aurora ahecht$ nm -g /Volumes/Aurora/FirefoxAurora.app/Contents/MacOS/browser/components/libbrowsercomps.dylib kochbuch:mozilla-aurora ahecht$ ls -l /Volumes/Aurora/FirefoxAurora.app/Contents/MacOS/browser/components/libbrowsercomps.dylib -rwxr-xr-x@ 1 ahecht staff 263764 May 2 10:45 /Volumes/Aurora/FirefoxAurora.app/Contents/MacOS/browser/components/libbrowsercomps.dylib kochbuch:mozilla-aurora ahecht$
I noticed that the aurora binary was just half the size, and ran file on nightly and the shipped aurora: kochbuch:mozilla-aurora ahecht$ file /Volumes/Aurora/FirefoxAurora.app/Contents/MacOS/browser/components/libbrowsercomps.dylib /Volumes/Aurora/FirefoxAurora.app/Contents/MacOS/browser/components/libbrowsercomps.dylib: Mach-O universal binary with 2 architectures /Volumes/Aurora/FirefoxAurora.app/Contents/MacOS/browser/components/libbrowsercomps.dylib (for architecture x86_64): Mach-O 64-bit bundle x86_64 /Volumes/Aurora/FirefoxAurora.app/Contents/MacOS/browser/components/libbrowsercomps.dylib (for architecture i386): data kochbuch:mozilla-aurora ahecht$ file /Applications/FirefoxNightly.app/Contents/MacOS/browser/components/libbrowsercomps.dylib /Applications/FirefoxNightly.app/Contents/MacOS/browser/components/libbrowsercomps.dylib: Mach-O universal binary with 2 architectures /Applications/FirefoxNightly.app/Contents/MacOS/browser/components/libbrowsercomps.dylib (for architecture x86_64): Mach-O 64-bit bundle x86_64 /Applications/FirefoxNightly.app/Contents/MacOS/browser/components/libbrowsercomps.dylib (for architecture i386): Mach-O bundle i386
(In reply to Axel Hecht [:Pike] from comment #22) > I noticed that the aurora binary was just half the size, and ran file on > nightly and the shipped aurora: > > kochbuch:mozilla-aurora ahecht$ file > /Volumes/Aurora/FirefoxAurora.app/Contents/MacOS/browser/components/ > libbrowsercomps.dylib > /Volumes/Aurora/FirefoxAurora.app/Contents/MacOS/browser/components/ > libbrowsercomps.dylib: Mach-O universal binary with 2 architectures > /Volumes/Aurora/FirefoxAurora.app/Contents/MacOS/browser/components/ > libbrowsercomps.dylib (for architecture x86_64): Mach-O 64-bit bundle x86_64 > /Volumes/Aurora/FirefoxAurora.app/Contents/MacOS/browser/components/ > libbrowsercomps.dylib (for architecture i386): data That doesn't smell very good.
Flags: needinfo?(mh+mozilla)
That said, it's the i386 part that's missing, is the bug seen running as 32-bits or as 64-bits?
The zh-CN repack happened on bld-lion-r5-079 today, the other locale that happened there was en-GB.
I'm seeing the bug running as 64-bit. Comment 18 is consistent with browsercomps not being around. I expect about:permissions, about:sessionrestore, etc to also not work.
This is taking a lot longer than expected. I'm only about a third of the way through all locales (now on hu) and have not reproduced this bug yet. At this rate it's probably going to take me until 6 or 7pm this evening to get through them all. I can keep going through this but I'm not sure it's worth the effort. If this was a failure in build then is there some way they can check for this more easily? (In reply to Nick Thomas [:nthomas] from comment #25) > The zh-CN repack happened on bld-lion-r5-079 today, the other locale that > happened there was en-GB. en-GB did not reproduce this bug for me.
The en-GB happened first and failed, probably leaving a bad file in the signing cache: 2014-05-02 02:35:47,028 - Copying FirefoxAurora.app.tar.gz to cache /builds/slave/m-aurora-osx64-l10n-ntly-00000/signing_cache/dmg/276a996f0867138bb2b3bbb4f96abe1858b1b3b6 FirefoxAurora.app/Contents/MacOS/browser/components/libbrowsercomps.dylib: (Empty error message) tar: Error exit delayed from previous errors. 2014-05-02 02:35:49,671 - Error unpacking tar file /builds/slave/m-aurora-osx64-l10n-ntly-00000/build/mozilla-aurora/obj-firefox/i386/dist/l10n-stage/firefox/FirefoxAurora.app.tar.gz to /builds/slave/m-aurora-osx64-l10n-ntly-00000/build/mozilla-aurora/obj-firefox/i386/dist/l10n-stage/firefox Full log: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/05/2014-05-02-00-40-03-mozilla-aurora-l10n/mozilla-aurora-macosx64-l10n-nightly-en-GB-bm86-build1-build4319.txt.gz I propose I disable/clobber that slave, and redo nightlies for en-GB & zh-CN on mac.
Moved bld-lion-r5-079:/builds/slave/m-aurora-osx64-l10n-ntly-00000{,.bug1004992} and rerunning zh-CN. Busted build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014/05/2014-05-02-00-40-03-mozilla-aurora-l10n/firefox-31.0a2.zh-CN.mac.dmg New build will go in a later dated dir and firefox/nightly/latest-mozilla-aurora-l10n.
The new build in comment 30 works for me.
I can confirm. The test failures for that build are fixed. Mozmill no longer fails in running the tests.
After some discussion on IRC we've decided this no longer blocks. I tested that Firefox 30.0a2 zh-CN updates to a fixed Firefox 31.0a2 zh-CN 2014-05-02 build on auroratest and it does. Nick Thomas is going to file a bug to figure out why these repack failures are happening, but we are not blocking Aurora updates on this investigation. Thanks everyone for your help.
I can reproduce on the English nightly on Win8.1 update1. For the last 2 nightlies at least.
Product: Core → Firefox Build System
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: