-
-
Notifications
You must be signed in to change notification settings - Fork 338
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix for z-index / transparent background / stacking of UIViews issue #98
Conversation
It looks amazing! so thanks! Just le me please a few days to go deeper into the changes. |
No worries, tested with iOS 8 & 9. On iOS 8 |
Hi @1N50MN14
I'm using iOS9.1. |
@gbhrdt I'm not getting any of those erros on iOS9.1, have you placed a z-index css property on the video element(s)? |
@1N50MN14 I did not change anything from my previous setup, so no, I did not add a z-index property. But shouldn't it work without it as well? I could go into some deeper testing tomorrow. |
@1N50MN14 Alright, I just realized I had some positive z-index set for one video element, because I wanted to place it above the other video element. Edit: The problem is probably my overall CSS, which might be ovarlaying the videos (I'm using Ionic). We should add that one to the documentation. |
I think it should handle non-negative z-indexes, having it spew errors when the z-index is positive doesn't make any sense. This new behavior should land as non-breaking and should augment, not replace, the old behavior. |
@gbhrdt Stacking of the videos on top of each other should work fine, make sure you set the background color of your HTML body to rgba(0,0,0,0) as those views are placed behind the HTML UI View. This too will be added to the documentation should the PR pass. Edit: Yes you're right I haven't updated the documentation along with the PR, will do so once it passes. |
Hi all, sorry for the delay (holidays...). So this PR goods nice but by reading comments above I would like to ask: are there any issues with the negative z-index? |
@ibc There shouldn't. The PR does however expect the z-index style property to be present (as specified here |
@1N50MN14 let me understand that. Currently (I mean, before this PR) nothing fails if the video has no CSS |
I mean it's really straight forward (https://github.com/1N50MN14/cordova-plugin-iosrtc/commit/386d0479f845a3b766f1649c08b3478a77bbedb0?diff=unified#diff-d70c63d9377ee3067943b8ec4cf9fda5R183) - there's no way for the plugin to know how to order the video UI views unless you tell it to via z-index, which would be a matter of documentation. |
@1N50MN14 that's unfortunate. Wouldn't a default value of 0 avoid that? |
With the current behavior (pre PR) videos do not need a z-index. If there are two videos then the last one is placed on top of the previous one (unless they have a z-index). We cannot mandate the user to place a z-index. If not set, the library should default to z-index 0 and things should work as before. Is there any problem to behave like that? |
@ibc Yes that would be problematic because a z-index of 0 (or positive z-index) referrs to a video element that we don't want to touch, whereas a negative z-index refers to a video element which we want to create a video UI view of, z-index will be used for sorting its order.. |
The app could still contain a "standard" video element that has nothing to do with the plugin, and we don't want to touch those. So the way to tell the plugin which videos we want to touch is by assigning a negative z-index on them and if none are present then naturally we'd have a scream. |
(I realize that's not W3C compatible but I can't think of any other solution, any suggestions are welcome) |
Now I'm totally lost. What does it mean that we don't want to touch a video element with 0 or positive z-index?
Of course. How is that a problem within this issue/PR? I would need a detailed documentation about the PR behavior, so I will first explain how things work before this PR: Current behavior
Now I would ask for a similar "documentation" regarding the PR exposed in here :) |
New behaviour
Edit: Finally, the HTML View now has transparent background color by default, so you could see the native video views beneath it. |
@@ -99,6 +100,13 @@ module.exports = function (context) { | |||
fs.appendFileSync(xcconfigPath, swiftOptions.join('\n')); | |||
debug('file correctly fixed: ' + xcconfigPath); | |||
|
|||
var result = fs.readFileSync(MainViewControllerPath, 'utf8') | |||
var rep ='theWebView.backgroundColor = [UIColor blackColor];'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is that unused var rep
for?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That line should be stripped out, sorry about that.
Is the PR tested when a MediaStream is closed (so I mean this method in func close() {
NSLog("PluginMediaStreamRenderer#close()")
self.reset()
self.elementView.removeFromSuperview()
} |
@ibc I don't believe so |
I'd like to clarify that I am not a iOS expert, nor a |
Ok that works for me, I mean I've been using the changes for 2 weeks without any issues. Can you guys also try to give this PR a shot to make sure all works as expected? |
I tested it over the weekend and everything seems working fine when using the negative z-indexes. Also, if no or a positive z-index is given, it works like before. I don't really know where these errors came from. Maybe I forgot to re-add the ios platform to my project when migrating to the new PR in order to re-run the hook, at first. |
@gbhrdt Yes I have a PR for that, but I can not do anything just yet until this PR is merged. |
@ibc Are you planning on merging this PR? |
@@ -1,3 +1,7 @@ | |||
/node_modules/ | |||
/TODO | |||
/NO_GIT/ | |||
/lib/libWebRTC-LATEST-Universal-Release.a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't understand why libWebRTC-LATEST-Universal-Release.a
is removed from the repository.
@1N50MN14 some points:
Please do that and I'll merge it today :) |
Hello @1N50MN14, While debugging I discovered that z-index is not read correctly from css on a video element. Could you please provide with some examples? The following one, doesn't work: #videos {
video::-webkit-media-controls { display:none !important; }
#remote-video {
video {
opacity: 0.5;
object-fit: cover;
z-index: -3;
}
}
#mini-video {
z-index: -2;
}
} #videos
video#mini-video(autoplay muted)
#remote-video
video // i cannot access this element directly since it is injected by a 3rd party library Thank you for your great job! |
Hello @1N50MN14, I am also trying to test this feature, but no success. The video always remains in the top. Could you provide a sample to code to test it? thank you! |
Hi guys, this PR was submitted four months ago since then the code base of the plugin has changed, if you see earlier comments it used to work. In the meantime I stopped using this repo in my project, I've been relying on my own private fork which I have been maintaining separately for the past three months with a code base that is very divergent by now. I can try to fork this repo again and revisit this this issue next week when I have some free time and a submit a new PR. |
@1N50MN14 would there be any chance of having access to that private fork? :) |
@jsampedro77 Not at the moment simply because there are constantly breaking changes at this point (updated the APIs, cordova-ios4 support, Android support which have been adding some complexity etc) and I won't be able to help you, but I will open source it as an independent project down the line possibly in 12 weeks from now. |
I can spend some time on this if somebody really guarantees that the PR works as expected and provides HTML example codes and/or proper documentation of the I just cannot merge it as it is because I don't have such requested information and I've read (here) some users commenting that it does not work as expected. Unfortunately I don't have time to test it and I cannot merge something that I cannot even properly document in the plugin API and could break some running apps. |
@1N50MN14 I too am looking forward to trying your full screen solution when you make it public. For now I've resized the vids to 90% height. |
Ohai! I finally found some time to test the patch out. It does not work in its current form. But it does with some tweaks. Result: https://www.dropbox.com/s/wcnbrqy0yg18d6a/2016-06-10%2015.54.41.png?dl=0 I tested it with both UIWebView and WKWebView and the result is the same, so that's great. The adapted patch is here: https://github.com/saghul/cordova-plugin-iosrtc/tree/stacked-uiview The result you can see in the screenshot works as follows:
If all those are met then the trick works. The current state of the patch doesn't seem to properly handle positive z-indexes, I'll try to get that sorted out and send a PR (if @1N50MN14 is OK with that). |
@saghul The PR intentionally does not handle positive z-indexes and it shouldn't because you might have
|
I don't necessarily disagree, but int its current form it's very weird that if no z-index is set then the plugin's videos are not displayed. (principle of least astonishment and all that).
I know. I just pointed it out because someone might have thought changes are required after migrating to cordova-ios 4.
Agreed.
Thanks, appreciate it! |
@saghul Yup you make a good point, awesome, well done! |
Ok, got it working! Please see: #179 I took a different approach for ordering the views from the original patch by @1N50MN14 which makes it (IMHO) simpler: add the video elements to the webView's superview, and use the layer's zPosition to take care of the ordering. See the (detailed) commit message in the pull request for a more thorough explanation. |
Closing this PR in favor of @saghul's |
This fix allows for:
NOTE:
video::-webkit-media-controls { display:none !important; }
must be added to the CSS to hide video controllers, maybe this should be added to the documentation.