Firefox Inspector output doesn't match rendered page - javascript

Question
I have a situation where the Firefox page render does not match the inspector html- that is, if I copy the inspector's outerHTML into a new document, it renders correctly. How is this possible?
Is this definitely a Firefox bug, or is there some intermediate render state where the inspector output has been updated but the page view hasn't? (If so, how would I force the render to progress past this intermediate state?)
Extra Details
I can also "fix" the render by manually (in the inspector) editing the attributes that aren't displaying correctly.
Specifically, for example, I might have a case where the code is calling setAttribute('width',10), which causes the inspector to say width="10" but causes the page to display whatever the width was previously set to. If I manually replace the width="10" with width="10", nothing happens; however, if I change width="10" to width="11", the width displays as 11, after which I can set the width to 10 again to make it display correctly.
Unfortunately, I have not yet been able to devise a simple example demonstrating this. My specific case is entangled with a fair amount of rendering code and involves changing dimensions on svg foreignObjects, but I'm mainly interested in the answer to the general question of how the inspector and page render can ever be out of sync.
(I have not been able to reproduce the issue in any other browsers, because Firefox is currently the only one that actually handles foreignObject correctly.)
Firefox Version: 51.0.1 (64-bit) on Mac 10.10.5
Updates
The main question still stands, but I'm increasingly thinking that a subtle Firefox bug is at the root of this. Some reasons:
Refreshing the page sometimes changes the behavior and sometimes doesn't.
I have tried adding getBBox calls right after each setAttribute, to force the browser to recalculate layout. This seems to work for every foreignObject- except for the first on the page. (However, sometimes the first one shows up- seemingly without anything being changed.)
JQuery's .attr seems to produce different behavior than .setAttribute and .setAttributeNS

Related

Why does Firefox lag using NVDA on a page setting textContent?

Recently I've been testing my website using screen readers and ran into a page that lags like crazy when using NVDA. More specifically:
All browser actions are substantially delayed, but NVDA itself runs perfectly fine
For example, the page normally loads in its entirety in less than a second, but with NVDA active, the first image can take several minutes to render
Refreshing the page takes several minutes to execute
Even switching or closing the tab takes several seconds
After some extensive debugging, I isolated the issue into a rather specific set of criteria causing the slowdown:
This only happens on Firefox (I'm currently on Firefox 90); Chrome and Edge are fine
This only happens with NVDA; VoiceOver on Mac is fine even on Firefox. I do not have JAWS.
The action causing a slow down is setting an element's textContent on every requestAnimationFrame, so it's happening dozens of times per second
I am uncertain if this is experimentally significant, but I'm running on Windows 10 Home
I managed to scrape together a minimal CodePen example. I used CodePen here because the simplest way I could replicate the issue was by refreshing the page. In the example is a refresh button that activates a spinner, so if the page is fast the spinner will show up for only a brief moment; if it's slow then you'll get to observe the spinner in all its glory.
What I see when I try to refresh:
So while I isolated what is causing the issue, I have no idea why this is happening and hence how to solve my original page's problem without deactivating the widget outright.
What might be the underlying cause(s) of Firefox/NVDA slowing down on a page setting textContent?
Is there an alternative to setting textContent that I can or perhaps should consider?
Is this perhaps an issue that should be filed directly with either Firefox, NVDA, or both?
Thank you!
Addendum:
NVDA Github Issue: This open issue indicates long pages are slow to load, which may be related to my problem
My Website's Page: The page on my website I'm talking about

IE10 IE11 displays "This page can't be displayed" On large DOM - works in firefox

I am working on an web application in MCV asp.net that needs to work in IE. Loading the application with data for some customers we get the "The page can not displayed" using IE10 and IE11.
More details are
It works in Firefox.
The error is only there for large pages = larger DOM
An exampel of a large page is a body of 4.6MB measured by Fiddler
For small pages there are no problems
The error page apears instantly when loading a customer
We have tried the following, but with no luck:
Removing stepwise elements from a big page and at some point it will start working, since it just removing sets of the same elements, nothing is being removed that could couse the problem - maybe its something with the size of the http-response?
Changed some IE settings
Stripping away all Jquery and CSS, to see if it was some DOM traversal issues
Tjekking the http-response to look for any bugs - non found
Google around seams that IE will show this page in some situations, but not found anything to fix this problem, where the application works on some pages but not on others.
Any suggestions?
The answer to why it does not work in IE is that you can not have more then about 200 AntiForgeryTokens, above that will make IE not load the page.
The quick solution: reduce the number of AntiForgeryTokens, we could do it by not having a delete form per element.

Debugging Strategy for Mysterious Inline Attributes

for a webapp I'm working with jQueries draggable and droppable function. Everything works fine in Chrome and Safari, but in Firefox there is a something weird going on: After dragging an element it gets inline height and width attributes. I already searched my code but can't find the bug.
Is there any way (with devtools for example) to trace back where this particular attributes come from (scripts, browser, ...) and to determine what exactly triggers these mysterious attributes?
Thank you!

Internet explorer browser effective area

Given a complex JS application produced by GWT I need to use the complete browser area WITHOUT let scrollbar compare but not disabling them because there's a couple of exception to the rule, i need then to calculate the client area and since the tool selected it would be better directly in GWT but as it is supported also pure JS solution are acceptable.
as usual all browsers (chrome, safari, ff) except IE11 works fine with a standard solution of
rootPanel.setPixelSize(Window.getClientWidth()-1, Window.getClientHeight()-1);
but when it's used in IE11 on a screen 1440x900
the value of getClientHeight is 1440x845 (seems ok) but after rendering using this space scrollbars compare wasting space, exactly 10pixels..
rootPanel.setPixelSize(Window.getClientWidth()-1, Window.getClientHeight()-10);
seems to solve..where are gone this 10 pixel comparing the result with other browsers?
I think contents are not relevant since the size is set on body and first div
<html>
<head>...
<body style="width:1439;height:xxx;">
<iframe out of visibility (position absolute and visible false
<table style="width:1439;height;xxx">
and so on
Any guess where 10pixel can be lost?
Edit: I was forgetting an important detail: all happens when browser is maximised, if the browser is n't all seems working as expected!!!
Edit: looks like something close if not the same of
$(window).height() issues in IE and FF
change just the origin of my JS code that comes from GWT but at the last stage should be the same, but still not solution
Solved: when maximized the actual size is available late...the resize must take the size in a deferred moment, the module load usually implemented in GWT isn't the right time for this browser in the specific state..

Very strange iframe event behavior

This question has me completely stumped. Since it's in a browser extension, I can't post my code.
The issue is apparently that mouse events inside the iframe (hovering over a link, over text, selecting...) are off by about 200px, this includes right clicks as shown in this screenshot:
The red dot is the actual mouseclick location. Again, since this is an extension (I'm actually doing the JS part in Tampermonkey, it's easier) I can't try it out in other browsers so it might just be chrome.
The iframe is to contain third-party dynamically loaded content so I can't use a div or other element. It's also reused and is dynamically inserted on load.
This also doesn't happen the first time content is inserted instead it takes a few "cycles" to appear.
Any ideas?
This was apparently a Chrome bug, albeit a strange one. I started having other issues so I reinstalled Chrome and upgraded to Windows 8 (I was planning to anyway), the bug seems to have gone away.
EDIT: It just came back, it turns out that the issue was that I was using -webkit-transform: scale() to show and hide the frame with a transition, removing this fixes the issue.
So, to all those with iframe mouse event issues in Chrome/WebKit: check all of your transforms and any CSS3 effects, try removing them one at a time.

Categories