This is working as intended and as per the documentation. You'll have to strip the hash part for the API, then loop through the resultant array and compare each item's url against the original full URL.

However, I agree it'd be nice if the API handled it automatically.

wesam.wesam.co@ Thanks for the issue.

Request you to provide the extension where this issue can be reproduced which will help in further triaging of the issue.

Thanks..

Thanks for your input woxxom.
is it a it a feature?
treating all chrome-extension:// urls with same-static.html/#/file/and-any-fragment as one? for cases where the options page is already open and after the user clicked on a link with hash fragment to jump to element/a page section?

if you try opening options page from the options page (as the active tab),
while a new-tab tab is one of the open tabs in the window,
it goes from the options tab to the new-tab tab every time.

see these GitHub issues, tries getting static html files loaded from disk to work with /routes didn't succeed unlike hash fragment routes
https://github.com/angular/angular/issues/13948#issuecomment-300481789
https://github.com/DevWurm/angular-electron-seed/issues/9

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

pushstate is disabled for files loaded from disk,
https://bugs.chromium.org/p/chromium/issues/detail?id=301210#c7

I can't use anything other than hash fragments

thanks Susan, okay will do this hour.

I'm still now done working on the extension boilerplate repo before publishing.

here's a zipped bundle in the mean time

here it is https://uploadfiles.io/9h3i7

the "attatch a file" anchor tag button is not working with this url: https://bugs.chromium.org/p/chromium/issues/detail?id=847612&can=2&start=0&num=100&q=&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified&groupby=&sort=#

Regardless of the theoretical possibility this feature gets implemented in the [distant] future, you can certainly use DOM History API in extension pages right now, since that file:// scheme bug is completely unrelated.

oh is it completely unrelated?  since file:// and chrome-extension:// are a different schemes?
I will re-investigate that now,

yesterday I tried setting in the manifest file paths to options, popup, backgrounds pages to
samefile.html/options ..etc. and it did parse the manifest and load even though it's a weird path,
however, the Angular framework threw errors related to the router and browser security. 

oh and in #6 I was asking if it is a feature and not a bug. I think you misunderstood something.

Since the extension pages aren't served by a server, manifest.json can't have URL paths after the target html file. Those are relative file paths, not URLs. Also, just because the word file is mentioned, that bug about content scripts inside a file:// page doesn't become any more related to extension pages that have chrome-extension:// URL, have a proper non-null URL origin, and don't have content scripts.

ah, I see my faulty logic and inadequate comprehension of the quick research I did. 
I appropriate your input/comments.

i'm developing a cross-browser extension boilerplate that is so simple yet modern, performant (smallest bundle size, fastest loading speed with code reuse and dynamic loading enabled by code splitting and loading by the framework) 
and a good development experience and speed (with auto/live reloading and sourcemaps for debugging).

just pushed it, here it is: https://github.com/wis/KISS-Angular-TypeScript-Live-Reloading-WebExtensions-Boilerplate

but sadly these 2 issues (2nd is  issue 849015 ) are blockers.

as a result of*
appreciate* 

the pushed manifest.json has options_ui.open_in_tab set to false, to test opening options tab bug (from browser action icon context menu) set it to true.
 
there is no issues when setting options_ui.open_in_tab to true, so it's prob. a bug with the code that checks if options tab is already open and gets it if so to make it active tab.

hope it's possible to resize the options cr-dialog (in chrome://extensions) enough. so this issue stops from being a 2nd blocker.

wesam.wesam.co@ Thanks for the update.

Tried loading the given extension on Windows 10 on the latest Canary 69.0.3466.0 in comment #17 and unable to load the extension.
Can see the error "Failed to load extension" while trying to load the same.

Can you please provide a sample extension files in zip format which will help in reproducing the issue.

Thanks..

was it the zip file uploaded in comment #10?
because that one is a prebuilt extension ready to unzip and load.

you might have downloaded the repo from github and tried loading the extension without building it first.
you need to have node js installed and to run 'npm install' then 'npm build'
in the command line in the source code directory before you load it.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot