If I’ve said it once, I’ve said it a thousand times, the Modern Web Browser Control (MWBC) is simply not a finished product, not nearly tested properly.
Here’s yet another issue with it!
I’ve been trying, in vain, to migrate an HTML page that references web based resources (JS, CSS) to instead use local versions. This is super simple to achieve with traditional browsers, however proving to be a nightmare with the MWBC!
Normally, you simply update the HTML page from
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.7.1/jquery.min.js" integrity="sha512-v2CJ7UaYy4JwqLDIrZUI/4hqeoQieOmAZNXBeQyjo21dadnwR+8ZaIJVT8EE2iyI61OV8e6M8PP2/4hpQINQ/g==" crossorigin="anonymous" referrerpolicy="no-referrer"></script>
to
<script src="../js/jquery.min.js"></script>
Easy, right!
However, things quickly fall apart with the MWBC!!! (AGAIN)
Because of this stupid requirement to prefix everything with https://msaccess/ (hurdle #1), we need to now use absolute paths everywhere (hurdle #2). Not necessarily the end of the world, but does require editing all the files involved. This may also require editing in real-time via your database which can be trickier (hurdle #3).
So, now we’d need to do:
<script src="https://msaccess/C:/Dev/menus/js/jquery.min.js"></script>
Great, right?
Well, maybe …, but sadly not in my case.
If you are lucky enough to be dealing with simple, straightforward scripts, CSS, the above will get things functional. However, if you are using more advanced resources that use common chaining approaches, then you’d need to alter each other files calling src.
but that won’t work as you will see in a moment!
A Concrete Example You Say
Easy. The Font-Awesome CSS!
So we would normally simply call:
<link rel="stylesheet" href="css/font-awesome.min.css">
and then modify it for Access usage by doing:
<link rel="stylesheet" href="https://msaccess/C:/Dev/menus/css/font-awesome.min.css">
The issue being that the CSS file itself includes statements like the following to point towards font files:
@font-face{font-family:'FontAwesome';src:url('../fonts/fontawesome-webfont.eot?v=4.7.0');
Now to make this work locally, we need to prefix the src with the file protocol, so:
@font-face{font-family:'FontAwesome';src:url('file://C:/Dev/menus/fonts/fontawesome-webfont.eot?v=4.7.0');
but for Access, we need to include the https://msaccess/ protocol and we can’t have 2 protocols! So Huston, we have a show stopping problem here! (Show Stopper #1)
So the following do not work:
@font-face{font-family:'FontAwesome';src:url('https://msaccess/file://C:/Dev/menus/fonts/fontawesome-webfont.eot?v=4.7.0');
@font-face{font-family:'FontAwesome';src:url('file://https://msaccess/C:/Dev/menus/fonts/fontawesome-webfont.eot?v=4.7.0');
@font-face{font-family:'FontAwesome';src:url('https://msaccess/C:/Dev/menus/fonts/fontawesome-webfont.eot?v=4.7.0');
@font-face{font-family:'FontAwesome';src:url('https://msaccess/../fonts/fontawesome-webfont.eot?v=4.7.0');
etc., etc., etc.
Some will say this is advance usage, but it truly isn’t. This is pretty basic simply making a webpage run locally and is quite common practice.
Realistically, if we’ve authorized a given resource file, then subsequent downstream linked files should automatically be authorized. Kinda makes sense!
Better yet! Ditch the useless https://msaccess/ which is just one more blunder in the MWBC implementation! This way things will simply work as they would normally with any common browser! (shouldn’t that be the goal). Because of the whole https://msaccess/ we have no way to test pages locally anymore and have to do all testing through Access which is far from ideal and plagued with a variety of problems.
Something like font-awesome is a VERY common styling used in countless webpage and is but one example of a common chaining technique used in CSS. The fact that Microsoft didn’t allow for this, obviously never did proper testing, illustrates the wide gap between their development and real-life usage.
So needless to say, there are numerous instances where it is simply impossible to run as local webpages via Microsoft Access’ Modern Web Browser Control due to this issue and that the only solution is to run web pages using resources online only which is pure non-sense!
What should have taken me 10 minutes to do (at the most) for normal web browser usage has turned into 14 hours trying to come up with a way around this Access mess and never getting a solution beyond simply knowing it doesn’t work.
Hey Microsoft, A Fix Please!
If ever you wish to see such issues resolved, please take 30 seconds of your day to upvote my Feedback Portal suggestion:
Remember, nothing will get addressed, the product will not be improved upon, if people don’t support the various suggestions people input on the Feedback Portal site. Even with support there are no guarantees!