RESOLVED FIXED 79800
[Qt] Fix build for WK2, do not use enum type if values can be outside the enum
https://bugs.webkit.org/show_bug.cgi?id=79800
Summary [Qt] Fix build for WK2, do not use enum type if values can be outside the enum
Caio Marcelo de Oliveira Filho
Reported 2012-02-28 08:49:00 PST
[Qt] Fix build for WK2, do not use enum type if values can be outside the enum
Attachments
Patch (4.59 KB, patch)
2012-02-28 08:51 PST, Caio Marcelo de Oliveira Filho
no flags
Caio Marcelo de Oliveira Filho
Comment 1 2012-02-28 08:51:09 PST
Kenneth Rohde Christiansen
Comment 2 2012-02-28 08:55:32 PST
Comment on attachment 129269 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=129269&action=review > Source/WebKit2/ChangeLog:10 > + We have two different enums called NavigationRequestAction. If we use one of them > + to store the variables, compilers can rightfully warn about comparison with > + values from other enums. why do we have that? ain't they namespaced? > Source/WebKit2/ChangeLog:12 > + We might revist the strategy of exposing different enumerations in experimental, revisit
Csaba Osztrogonác
Comment 3 2012-02-28 09:00:23 PST
Comment on attachment 129269 [details] Patch rs=me to fix the build now, but we _really_ need to refactor using two NavigationRequestAction enum. :-/
Caio Marcelo de Oliveira Filho
Comment 4 2012-02-28 09:03:47 PST
Caio Marcelo de Oliveira Filho
Comment 5 2012-02-28 09:09:19 PST
Comment on attachment 129269 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=129269&action=review >> Source/WebKit2/ChangeLog:10 >> + values from other enums. > > why do we have that? ain't they namespaced? We can't choose one or other to be the type of the property since the values come from different enums. Namespacing is not an issue here. The QtWebKit API exposes a property that takes values from two different enums.
Csaba Osztrogonác
Comment 6 2012-02-28 09:12:57 PST
Reopen, because we need a proper fix instead of workaround.
Caio Marcelo de Oliveira Filho
Comment 7 2012-03-02 09:07:19 PST
(In reply to comment #6) > Reopen, because we need a proper fix instead of workaround. I prefer closing this since it was intended just to revert the code back to its previous state. See bug 80164 for changes that deal with the workaround.
Note You need to log in before you can comment on or make changes to this bug.