Comments (27)
Might be relevant:
RMLUI_ASSERT(!parent || !_parent)
.../libRocket/Source/Core/Element.cpp:1913
from rmlui.
Same thing in Element::GetStyleSheet():
const SharedPtr<StyleSheet>& Element::GetStyleSheet() const
{
if (ElementDocument * document = GetOwnerDocument())
return document->GetStyleSheet();
from rmlui.
Hmm, that's strange, thanks for reporting.
Looks like the owner_document is set to an Element that is not an ElementDocument. I'm out traveling now, but will have a closer look at it once I have some more time.
from rmlui.
Yeah, I think culprit here is that I'm attaching a document to an "iframe" element, which a regular ekement and that worked in libRocket but not in RmlUi.
from rmlui.
Ah, yeah, I'm not sure how that would work out.
So this document under the iframe is an ElementDocument, could the document be replaced by a normal Element? Can I ask what you are using this for? :)
from rmlui.
I'm using this to create embedded iframes - basically, a document within another document. Each document has its own set of scripts, listeners and styles attached so that makes it impossible to replace them with normal Elements.
By nesting documents you are also able to pass events between them.
from rmlui.
Sounds good! I'll have a closer look at it.
from rmlui.
I don't see how an Element can be set as an owner_document. Are you setting this manually somehow?
How do you create and attach the document?
from rmlui.
I don't see how an Element can be set as an owner_document. Are you setting this manually somehow?
How do you create and attach the document?
Here's the code (commented out for now):
https://github.com/Qfusion/qfusion/blob/librml/source/ui/widgets/ui_iframe.cpp#L115
from rmlui.
I cannot reproduce this issue. I do spot a potential issue with the commented out code though. You are wrapping a non-owning raw pointer in a new smart pointer, which will lead to a double delete at some point (memory corruption), and other potential issues wrt. ownership.
Can you try replacing the commented out code with the following:
assert(rocket_document->GetParentNode() != nullptr);
AppendChild( rocket_document->GetParentNode()->RemoveChild(rocket_document) );
Assuming the document is still attached to the root (as after loading the document).
There may be other issues lurking though, but I cannot see the owner document ever getting changed in an ElementDocument. In my own testing I'm getting a different assertion failure, not sure if it is serious but I will investigate further.
from rmlui.
Doh, you're right - that was indeed an oversight of mine. Changing the code to what you suggested fixed the crash, however I can't get the child document to get positioned properly: its position is always seems to be absolute no matter what, even after tweaking the line in ElementDocument() constructor from:
SetProperty(PropertyId::Position, Property(Style::Position::Absolute));
to
SetProperty(PropertyId::Position, Property(Style::Position::Relative));
The focus is also messed up. Manually calling DirtyPosition() didn't do anything.
from rmlui.
Finally decided to try the Debugger plugin and I must say that I'm pretty damn impressed. Here's what it has to say about the inlined document and its parent iframe "profile_container":
from rmlui.
Just for reference, here's how it is supposed to actually look (the inlined document should be positioned at the top left corner of the ancestor's box):
from rmlui.
Can you try this change:
There is one other issue I've recognized. The layout needs to be updated manually for the iframe document. Did you have to do this before?
from rmlui.
Forgot to mention, in addition you still have to set the position property manually, or set the parent to position: relative
.
Okay, I think I understand the need for manual layouting. The dirty layout is set on the nearest document, instead, it needs to be set on the outer document. I think it's easier to just do it manually rather than work around it inside the core library.
from rmlui.
Hm, it has always worked for me without manual positioning or dirtying of the parent document. The possible reason being that for the iframe element, i'm doing the following:
SetProperty( "display", "inline-block" );
SetProperty( "overflow", "auto" );
from rmlui.
But yes, that commit has resolved the issue for me, thanks!
from rmlui.
Good to hear, no problem!
I think the best solution for iframe is to create a custom IframeElement, which is just a simple replaced element. Then, have the ElementDocument attached to the Context as normal, and draw it in the position of the iframe. I'd rather spend my time on other priorities now though, but something to consider if we want to support iframe
natively.
from rmlui.
Good to hear, no problem!
I think the best solution for iframe is to create a custom IframeElement, which is just a simple replaced element. Then, have the ElementDocument attached to the Context as normal, and draw it in the position of the iframe. I'd rather spend my time on other priorities now though, but something to consider if we want to support
iframe
natively.
If I'm getting this right, it isn't quite the same thing, as you'll end up with missing scrollbars in case the inline document overflows its parent iframe.
from rmlui.
It would work like the html iframe element, we would need width and height defined on the iframe, which we would also use on the iframe body. And probably overflow: auto
by default, which should give the same behavior?
We wouldn't be able to have the iframe scale dynamically based on its content no, if this is the behavior you need. That is, width: auto
and height: auto
wouldn't make sense.
from rmlui.
No-no, that's not what I mean. The way it currently works for me is exactly the way the the html iframe works. And ye, it has fixed width and height set in css, and defaults to overflow: auto
and display: inline-block
in the code, which in turn causes the attached document to have position
set to relative
.
https://github.com/Qfusion/qfusion/blob/librml/source/ui/widgets/ui_iframe.cpp#L37
https://github.com/Qfusion/qfusion/blob/librml/source/ui/widgets/ui_iframe.cpp#L113
The iframe also subscribes to show
and hide
events of the parent and repeats the events for the framed document.
from rmlui.
Oh I see, then the behavior should be the same with how I described. The difference is that the document would not be a child of the iframe, but the context. Then the iframe (or context itself) would be responsible for setting the position and clipping of the document. This way we would avoid any potential issues with nested documents, and also ensure that inherited properties are not inherited "through" the iframe.
But of course, since it works now, I guess no need to spend time on this :)
from rmlui.
Yes, the way this works right now is alright by me :)
from rmlui.
Then it's all good :)
from rmlui.
Yup, just don't forget to merge the iframe branch into develop ;)
from rmlui.
Yup, I've merged the relevant parts now. Do you feel this is ready to be closed?
from rmlui.
Sure! Thanks again!
from rmlui.
Related Issues (20)
- [Effects branch] box-shadow Asserts with No converter specified HOT 7
- CSS Custom Properties HOT 1
- "contextmenu" (right click) event is not implemented HOT 3
- Use controllers in the menus HOT 7
- Issues with clip and transform properties when used together. HOT 2
- C Bindings, Arrays and Structs HOT 4
- RmlUi GLFW3 (Vulkan) causes amgpu driver crash HOT 13
- SetDensityIndependentPixelRatio does not cause a change with GLFW3 GL3 HOT 5
- Rml::SystemInterface::JoinPath not used when using RmlDebugger causes different resource search paths on my debug and release builds HOT 3
- Change `Element::AddEventListener` to take weak pointers to the event listener HOT 8
- Multiple animations with the same property on the same element not supported HOT 4
- Input elements display nothing on screen HOT 4
- Vulkan Backend does not work with Lottie animations over time HOT 7
- I noticed that there are other licenses in the folder, one of which mentions the GNU protocol. HOT 2
- Tga file loading does not work correctly, but not in all circumstances (and only in Windows!). HOT 5
- Multiple css styles are not supported HOT 5
- RCSS selector escaping HOT 3
- The default GLFW GL3 backend yields weird display HOT 4
- Support for mouseenter and mouseleave events. HOT 3
- Support for Modulus operation in expressions HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rmlui.