Closed Bug 1406785 Opened 3 years ago Closed 3 years ago

search in local sphinx doc no longer works

Categories

(Core :: XML, defect)

58 Branch
All
Unspecified
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox58 --- affected

People

(Reporter: lilydjwg, Unassigned)

References

Details

Attachments

(1 file)

29.63 KB, application/zip
Details
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
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
Flags: needinfo?(lilydjwg)
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.
Flags: needinfo?(lilydjwg)
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
Flags: needinfo?(lilydjwg)
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.
Flags: needinfo?(lilydjwg)
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
Flags: needinfo?(lilydjwg)
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.
Flags: needinfo?(lilydjwg)
Attached file minimal testcase
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.
Status: UNCONFIRMED → NEW
Component: Untriaged → CSS Parsing and Computation
Ever confirmed: true
Product: Firefox → Core
Hardware: Unspecified → All
There is no CSS in this test.
Component: CSS Parsing and Computation → XML
Flags: needinfo?(alin.deac)
(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
Flags: needinfo?(alin.deac)
I wonder if we're limiting the size of the document somehow. Henri, do you know?
Flags: needinfo?(hsivonen)
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:"
Deac Alin, could you please verify if this issue is fixed on the latest build? I don't see it anymore.
Flags: needinfo?(alin.deac)
(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
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(alin.deac)
Resolution: --- → WORKSFORME
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.
Flags: needinfo?(hsivonen)
You need to log in before you can comment on or make changes to this bug.