Context Help doesn't work for long section names, if Firefox is the default browser #12362
Comments
|
Hi, actually, Quentin, @feerrenrut, @michaelDCurran
|
|
Just to be sure @XLTechie, can you confirm that the anchor in the URL is spelled the same as the If I paste the following URL into Firefox, it opens to the right section: Though we actually write a file with a redirect, because we found that one of the browsers didn't like opening files with anchors from the command line. So the following is the redirect, then encoded to base 64 and written as a dataURL. This works pasted into Firefox. |
|
I haven't tested this again tonight, but that was the exact spelling and
capitalization I used.
The refresh URL you gave was an https URI, but
gui.contextHelp.writeRedirect() generates a file URI (I.E. works off
line), which it derives from globals.
I am not, however, talking about pasting into Firefox.
What happens if you paste that URL into a run dialog (The file based URL,
not the https one) with Firefox set as default browser on system?
My results are as described in the issue.
Personally I would like to rewrite context help to provide only the
appropriate section, in its own ui.browseableMessage, but don't know if a
PR would be welcome on that subject.
Not related to this issue, although it would certainly solve it.
|
|
Hi, as for a browse mode message with just the section content, that’s an extension of #2699, and I think that ought to be the “more useful” user experience. Displaying only the section content also allows me o prepare another add-on of mine to come to Core: Control Usage Assistant. Thanks.
|
|
@josephsl I had been waiting until the end of #11006 to propose it, but I
couldn't resist mentioning it here, as it would definitely solve this
issue.
If this issue is real, it's also probably the only way worth pursuing to
solve it from our side. But I would like someone else to confirm this
isn't some quirk unique to my setup.
|
|
@feerrenrut were you able to repro this?
|
|
Firefox was the browser that we couldn't get to work with anchors directly on the file URL. So none of the anchors mentioned work from the run dialog for me. Do they work for you? The reason I pasted in those data URI tests was to try to narrow down the cause of the issue. If those work, we can be more certain it is related to the local file system. I believe I have a long paths setting enabled in Windows which may give me different behavior than you. Just to confirm with Firefox as my default browser, I have tested pressing F1 in the check for updates dialog. It successfully takes me to anchor |
|
@XLTechie can you reproduce this also with NVDA last alpha and firefox 123? |
|
Yes. Just tested by pressing F1 on "Use UI Automation to access Microsoft Word
document controls" in Advanced.
The file opened in Firefox, but at the top of the table of contents.
Note that this is now Windows 11 instead of 10, Firefox 123, and a completely
different computer than when I submitted the issue.
@jcsteh this may be a Firefox bug in regards to file:// URIs with deep
relative anchors.
The annoying thing for reproduction, is that once it works, it continues working
thereafter, even if you clear the "visited" status from within Firefox and
close the tab. (I have an FF extension for clearing visited status)
As such, my local reproduction targets for this are dwindling.
|
Note. This is almost surely a Firefox bug (if it can be replicated). However it causes NVDA's Context Help to fail, which is why I'm posting it here.
Steps to reproduce:
Edit (2024): while it wasn't in the original STR, this can also be replicated by pressing F1 on any NVDA Settings panel item with a name that triggers this bug. Of course, since I'm not absolutely sure why some anchors trigger this bug and some don't, finding one of the broken ones may take a while. Currently, "
MSWordUIA" is triggering it for me.Original STR:
Attempt to open any context help URL from the run dialog, with Firefox set as your default browser.
For example, using the URL
file:///C:/Program Files (x86)/NVDA/documentation/en/userGuide.html, and appending one of the anchors below.This is if pasted directly into the dialog, so Windows has to derive the correct executable, similar to how gui.contextHelp does it. If you prepend with "
firefox.exe", the problem doesn't occur.Alternative STR:
Actual behavior:
On my system I am finding that:
#Introduction#GeneralFeatures#SystemWideParameters#RunCOMRegistrationFixingTool#PortableAndTemporaryCopyRestrictions#InstallWithIncompatibleAddons#CopyPortableConfigurationToCurrentUserAccount#WordAutomaticColumnAndRowHeaderReadingFirefox shows the correct address in the title bar, including the anchor, you just aren't at the anchor.
At first I thought this was because the anchors were over 25 characters long, like
#RunCOMRegistrationFixingTool(28 characters); but then I found that#GeneralSettingsCheckForUpdates(which is 30 characters), works fine.I now conclude that it relates to long anchors near the end of the document.
Expected behavior:
All anchors take one to the proper manual section under all circumstances.
System configuration
NVDA installed/portable/running from source:
Installed, portable
NVDA version:
(2021) alpha-22581,86fe20ff
(2024) alpha-31457,def4f332
Windows version:
(2021) 10, 20H2, 19042.928
(2024) 11, 23H2, 10.0.22621.3235
Name and version of other software in use when reproducing the issue:
(2021) Firefox 88.0 (64 bit)
(2024) Firefox 123.0.1 (64 bit)
Other information about your system:
Other questions
Does the issue still occur after restarting your computer?
Yes
Have you tried any other versions of NVDA? If so, please report their behaviors.
Same, see above. And many stables and betas in between.
If add-ons are disabled, is your problem still occurring?
Yes
Does the issue still occur after you run the COM Registration Fixing Tool in NVDA's tools menu?
Yes
The text was updated successfully, but these errors were encountered: