[FIXr]xul-overlay processing instruction pointing to inexistent file make mozilla enter in some kind of loop

RESOLVED FIXED in mozilla1.8beta1

Status

()

Core
XUL
P1
normal
RESOLVED FIXED
15 years ago
10 years ago

People

(Reporter: Cedric. S., Assigned: bz)

Tracking

Trunk
mozilla1.8beta1
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624

referencing an inexistent file in a <?xul-overlay ...> Processing Intruction in
a xul file make mozilla unable to load this xul file : mozilla never stops to
load it in fact.

Reproducible: Always

Steps to Reproduce:
drag&drop the linked xul page into the browser. 



Actual Results:  
It looks like it never finishes to download it. (Sandglass indefinitely, hit
ESCAPE to stop).

Expected Results:  
retry without the 2nd line, it's ok.

<?xml version="1.0"?>
<?xul-overlay href="inexistent-file.xul"?>

<window
  xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
  >
  
</window>
The XUL code uses Open() to load overlays.  Is the original XUL page in chrome?
 a file:// url?  An http:// url?  That is, what's the base URI for the relative
URI resolution?

Also, the implementation of Open() got heavily changed recently, so testing with
anything but a very recent nightly (like today's) is not very useful at this
point...
.
Assignee: hjtoi-bugzilla → hyatt
Component: XML → XP Toolkit/Widgets: XUL
QA Contact: ashshbhatt → shrir
(Reporter)

Comment 3

15 years ago
the bug also occurs in Mozilla 1.5 (release)
(Reporter)

Comment 4

14 years ago
The bug still can be reproduced in Moz 1.6 (realase)
I did this with a recent build. I tried to import a overlay from wallet into
calendar. Works fine, expect when wallet isn't there. And firefox/thunderbird
don't have it.

<?xul-overlay href="chrome://wallet/content/walletTasksOverlay.xul"?> is the
thing that fails. so, to answers bz's question: it's a chrome url, and a recent
build.
Created attachment 153010 [details] [diff] [review]
This should fix the problem
Comment on attachment 153010 [details] [diff] [review]
This should fix the problem

jst, would you sr?
Attachment #153010 - Flags: superreview?(jst)
Taking.
Assignee: hyatt → bzbarsky
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Priority: -- → P1
Hardware: PC → All
Summary: xul-overlay processing instruction pointing to inexistent file make mozilla enter in some kind of loop → [FIX]xul-overlay processing instruction pointing to inexistent file make mozilla enter in some kind of loop
Target Milestone: --- → mozilla1.8beta
Comment on attachment 153010 [details] [diff] [review]
This should fix the problem

- In nsXULDocument::ReportMissingOverlay():

+    nsresult rv;
+    nsCOMPtr<nsIConsoleService> consoleService =
+	 do_GetService(NS_CONSOLESERVICE_CONTRACTID, &rv);
+    if (NS_FAILED(rv))
+	 return;
+    nsCOMPtr<nsIScriptError> errorObject =
+	 do_CreateInstance(NS_SCRIPTERROR_CONTRACTID, &rv);
+    if (NS_FAILED(rv))
+	 return;
+    nsCOMPtr<nsIStringBundleService> stringBundleService =
+	 do_GetService(NS_STRINGBUNDLE_CONTRACTID, &rv);
+    if (NS_FAILED(rv))
+	 return;
+    nsCOMPtr<nsIStringBundle> bundle;
+    rv = stringBundleService->CreateBundle(
+	    "chrome://global/locale/xul.properties", getter_AddRefs(bundle));
+    if (NS_FAILED(rv))
+	 return;
+
+    nsCAutoString spec;
+    aURI->GetSpec(spec);
+
+    NS_ConvertUTF8toUTF16 utfSpec(spec);
+    const PRUnichar* params[] = { utfSpec.get() };
+
+    nsXPIDLString errorText;
+    rv =
bundle->FormatStringFromName(NS_LITERAL_STRING("MissingOverlay").get(),
+				       params, NS_ARRAY_LENGTH(params),
+				       getter_Copies(errorText));
+    if (NS_FAILED(rv))
+	 return;

Geez, I mean, could this get any more verbose? If there isn't one already,
wanna file a bug to make a non-pathetic API for our string bundle code (in
nsContentUtils for layout etc to use, if nowhere else), I mean, this is just so
unbelieveably sad.

sr=jst nonetheless tho :-)
Attachment #153010 - Flags: superreview?(jst) → superreview+
Dunno about string bundles, but bug 228205 should make the console service api
much easier to use (in particular, it should hide all the intl crap under the
console service).

I can still file a bug on a better stringbundle api if you want, though.
Summary: [FIX]xul-overlay processing instruction pointing to inexistent file make mozilla enter in some kind of loop → [FIXr]xul-overlay processing instruction pointing to inexistent file make mozilla enter in some kind of loop
Yeah, I think it'd be worth overhauling how we use the stringbundle service etc
too to hide some of its bloatiness behind a less bloaty API, since we use that a
fair bit for non-console service purposes as well. So please file a followup bug
on that (and CC me).
I think that patch should have nsXULDocument.h changes somewhere (now that it
broke the tree). :-)
Checked in for 1.8a3 or 1.8b or whatever this next milestone is.
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
And yes, I did check in the nsXULDocument.h change to fix bustage (just declares
the function in the obvious way).

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.