lilydjwg Reporter
	Description • 7 years ago

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20171008131700

Steps to reproduce:

* get a sphinx generated documentation, e.g. https://docs.python.org/3/download.html
* visit via file://
* search something


Actual results:

search doesn't complete, errors in console:

XML Parsing Error: not well-formed
Location: file:///..../searchindex.js
Line Number 1, Column 16:
searchindex.js:1:16
NS_ERROR_UNEXPECTED: 
jquery.js:4

This happens with and after 2017-10-07's nightly


Expected results:

search completes the same way in 2017-10-06's nightly

	Deac Alin
	Comment 1 • 7 years ago

Tested on Nightly 58.0a1 Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0 Build ID 20171010220102
and could not reproduced the issue(failed search and console error) following the steps mentioned above:
1. downloaded and visited via local file://  - file:///home/user/Documents/Download%20%E2%80%94%20Python%203.6.3%20documentation.html 
2. Ctrl-F and input search
3. Check Console

If this is not the case, would be great to have more exact steps to verify this, or/and a reduced test case if possible. Thank you

	lilydjwg Reporter
	Comment 2 • 7 years ago

Oh sorry I didn't make it clear: perform a search using the search form at the top right corner in page, not the find tool of the browser. Type anything in the input box saying "Quick search" and press "Go" button. It will submit to another page, which demonstrates the issue.

	Deac Alin
	Comment 3 • 7 years ago

Yeah, I figure that out in the meantime, but thanks for clarifying. Using the "Quick search" will direct to a different page (not local), and the search it's complete with no parsing error returned in console.

Can you please try with a new profile, you have the steps here: https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager
Also, please test if the issue can be reproduced in the safe mode of Firefox: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode
Thank you

	lilydjwg Reporter
	Comment 4 • 7 years ago

Not local? That surprises me. It should be a path like .../search.html?q=test&check_keywords=yes&area=default. Can you try to use the search.html file directly?

I'm testing with a new temporary profile with firefox-nightly -no-remote --profile an_empty_directory.

	Deac Alin
	Comment 5 • 7 years ago

Per my understanding, you run the entire site under the local host, so it makes sense that the Quick Search redirects you to local quick search. I think the best way to follow this through, is for you to attach a reduced Test Case (simplified example - of a local file you are using, so the issue can be easily reproduced), if possible, so further investigations can be done. Thank you

	lilydjwg Reporter
	Comment 6 • 7 years ago

Here is a minimal test case I can get:

Visit search.html and see the error in console.

The content of searchindex.js is not important. The size is. If it's greater than 32768 the console logs an NS_ERROR_UNEXPECTED error.

	Deac Alin
	Comment 8 • 7 years ago

Tested on Latest Nightly 58.0a1 on Linux X11; x86_64 and Mac 10.12.
I can confirm that the issue is present only with and after 2017-10-07's Nightly. lilydjwg Thank you for reporting it.

	Jet Villegas (inactive)
	Comment 9 • 7 years ago

There is no CSS in this test.

	Deac Alin
	Comment 10 • 7 years ago

(In reply to Jet Villegas (:jet) from comment #9)
> There is no CSS in this test.

Yes, you are right, at the moment it seemed the right component(my bad). Thank you

	Andrew Overholt [:overholt]
	Comment 11 • 7 years ago

I wonder if we're limiting the size of the document somehow. Henri, do you know?

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 12 • 7 years ago

I don't see  NS_ERROR_UNEXPECTED error when running attachment 8917910 [details] on the nightly 2017/10/17. The NS_ERROR_UNEXPECTED was fixed within the range  https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=20d57b9c4183973af4af5e078dff2aec0b74f928&tochange=f3da88fdee4ab79a2212f8d2d1efd37fb5009b58
I'd believe it's fixed by backing out bug 1405571, which was originally landed on m-c on 2017/10/7.

I see the below console message with the attachment 8917910 [details] cross various nightly builds though.
"XML Parsing Error: not well-formed
 Location: file:///Users/hsinyi/Downloads/minimal-testcase/searchindex.js
 Line Number 1, Column 1:"

	Hsin-Yi Tsai (she/her) [:hsinyi]
	Comment 13 • 7 years ago

Deac Alin, could you please verify if this issue is fixed on the latest build? I don't see it anymore.

	Deac Alin
	Comment 14 • 7 years ago

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #12)
> I'd believe it's fixed by backing out bug 1405571, which was originally
> landed on m-c on 2017/10/7.
Yes, it seems that the backing out of 1405571 fixed this issue aswell.
Tested on latest Nightly 58.0a1 Build ID 20171016220427 on Linux X11; x86_64 and Mac 10.12 and the issue is no longer reproducible. Thank you

	Henri Sivonen (:hsivonen) (away from Bugzilla until 2023-09-11)
	Comment 15 • 7 years ago

It seems that this is fallout from the CORS proxy calling OnStopRequest a second time and how the patch for bug 1405571 interacted with that.