Open 575755 opened 4 years ago
Hi, Please take this issue as a priority .
When a HTML tag is present in the raw source, but missing in the computed DOM, this may be a sign that there is a mismatch between XHTML and HTML (e.g. self-closing tags). Just a thought.
Hi Daniel,
We have only (.html) file for the physical content .In the below we have added two screenshots one is from browser perspective physical file and another one is from our code-base physical file .So we have compared both the file and tried to make changes in our code-base physical file as you suggested to check with the self-closing tags in the comment .
In that file one tag is given as self-closed tag. So we tried like by changing pre-closed tag as normal .. tag . after changing we are getting like this:
After changing all things also still same issue we are facing. So, We are not getting whether it is adding a duplicate tag or removing tag in the DOM structure in this particular issue. Because only for this tag Xpath is coming different.
Hi Daniel,
We have attached the screenshot of
perhaps this explanation helps? https://github.com/readium/readium-js-viewer/issues/747#issuecomment-714428559
Another thing comes to mind (which could explain the closing tag issue): HTML vs. XHTML file extension triggers different parsing behaviour in some web browsers, when the HTTP header content-type is not available.
Hi, We are facing issues with highlight feature when the migrated data coming up.
Please find the examples of old reader and new reader Xpath with the decoded details for same text below:
Old Reader:
L2h0bWwvYm9keS9wWzJdL2E6OnBhcmVudE5vZGUsL2h0bWwvYm9keS9wWzJdL2E6OnBhcmVudE5vZGUsMTgsMjc=
/html/body/p[2]/a::parentNode,/html/body/p[2]/a::parentNode,18,27
New Reader: L2h0bWwvYm9keS9wWzNdOjpwYXJlbnROb2RlLC9odG1sL2JvZHkvcFszXTo6cGFyZW50Tm9kZSwxOCwyNw==
/html/body/p[3]::parentNode,/html/body/p[3]::parentNode,18,27